Embed Size (px)
Citation preview
INTERFAZ INMERSIVA PARA MISIONES ROBÓTICAS BASADA EN REALIDAD VIRTUAL
JULIO 2017
Elena Peña Tapia
DIRECTOR DEL TRABAJO FIN DE GRADO:
Antonio Barrientos/ J.J. Roldán
Ele
na
Pe
ña
Ta
pia
TRABAJO FIN DE GRADO PARA
LA OBTENCIÓN DEL TÍTULO DE
GRADUADO EN INGENIERÍA EN
TECNOLOGÍAS INDUSTRIALES
INTERFAZ INMERSIVA PARAMISIONES ROBOTICAS BASADA EN
REALIDAD VIRTUAL
Elena Pena TapiaDepartamento de Automatica, Ingenierıa Electronica e Informatica Industrial
Escuela Tecnica Superior de Ingenieros Industriales - UPM
Trabajo de Fin de Grado
Dirigido por Antonio Barrientos y Juan Jesus Roldan
Junio 2017
ii ETSII UPM
Agradecimientos
Es difıcil decidir por donde empezar a agradecer a todas las personas quehan hecho posible este trabajo, ası que me remontare al inicio de los tiem-pos. Gracias Mama, por estar conmigo siempre, por escucharme, ayudarmey velar hasta el final por mis intereses. Gracias Papa y Pedro, por vues-tra 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, maximo exponente delmovimiento cotutor-amigo-surcador de deadlines. Siempre ayuda estar conalguien que confıa mas en ti que tu mismo. Gracias Antonio por escucharsiempre a tus alumnos, por tu ejemplo intachable y tus marrones conti-nuos. Gracias a todos los chicos del RobCib por dejarme invadir la sala dereuniones con las gafas: gracias Andres, por tu casi-cotutorıa; Mario por tusaportaciones con el brazo (robotico); y todos los demas (Pablo, Silvia, Jorge,David) por vuestras tertulias, vuestras crıticas constructivas y por hacermeretomar la costumbre del tupper. Ah!, y gracias Javi, por tus siempre utilesconsejillos.
Gracias tambien a todos los buenos profesores que he tenido a lo largo delgrado, y a mis amigos, companeros de clase y companeros de TFG.
No puedo dejar el terreno de la ETSII sin dar las gracias a los unicos, losinigualables DisSolutions. Porque sin ellos la escuela no tendrıa sentido. Nose si es porque aquı todo se magnifica (como en GH), pero habeis marcadoun antes y un despues de conoceros, ahı lo dejo.
“Rien dans la vie n’est a craindre, tout doit etre compris. C’estmaintenant 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 elmomento de entender mas para poder temer menos.)
Resumen
Los avances en tecnologıas inmersivas han dado lugar a nuevas herramientasde realidad virtual con un inmenso potencial para la mejora de interfacesroboticas. En concreto, se han detectado dos ambitos en los que el uso derealidad virtual puede resultar especialmente beneficioso. Por un lado, se en-cuentran las misiones multi-robot, que suponen un gran reto a los operadoresen lo referente a carga de trabajo y conciencia de la situacion (situationalawareness). Los operadores de estas misiones deben ser capaces de recibirlos datos de los robots, extraer la informacion relevante, procesarla, tomardecisiones y generar los comandos adecuados en el menor tiempo posible.En estos casos, es comun que lleguen a saturarse o pasen por alto aspec-tos claves para el desarrollo de la mision. Las interfaces de realidad virtualpueden ayudar en este sentido, dado que su alto nivel de inmersion favorecela asimilacion de informacion del entorno de forma natural, provocando asıuna mejora de la conciencia de la situacion respecto a la experimentada coninterfaces convencionales.
Por otro lado, el ambito de la teleoperacion de robots con actuadores com-plejos tambien supone un nicho interesante para esta tecnologıa. La realidadvirtual posee la capacidad de transportar al operador al espacio de trabajo,le proporciona informacion sobre las tareas a realizar y le permite comandarlos robots de forma intuitiva y precisa.
Es por estos motivos que en este trabajo se ha decidido desarrollar y probardos interfaces de realidad virtual: una interfaz de monitorizacion de misionesmulti-UAV y otra de teleoperacion de un brazo robotico manipulador de 6grados de libertad. En ambos casos se ha seguido la arquitectura del sistemapresentado en la figura 1. Los robots funcionan bajo ROS (Robot OperatingSystem), lo que permite su control y toma de datos a traves de un ordenadorcon sistema operativo Linux. Este ordenador se ha conectado a traves desockets TCP/IP a un segundo terminal con Windows, en el que se encuentrael software de diseno de videojuegos Unity y su plugin especıfico Steam VR,que facilita la conexion con las gafas de realidad virtual HTC Vive.
Figura 1: Arquitectura del sistema
La interfaz de monitorizacion reproduce el escenario de una serie de misionesde extincion de incendios y seguimiento de intrusos efectuadas en 2016 enla Universidad de Luxemburgo. En las misiones intervienen dos UAVs y unrobot terrestre, cuya telemetrıa y comandos se registraron de forma detalla-da para su posterior reproduccion. La interfaz permite seguir el desarrollode la mision a traves de su conexion con ROS. La informacion relevante semuestra de forma visual y auditiva (figura 2), con la aparicion dinamica defuegos y enemigos, el movimiento realista de los UAVs y una serie de ele-mentos adicionales que aportan datos sobre el estado de la mision en cadamomento. La interfaz incluye un modo denominado predictivo, en el que seintegra informacion extraıda de una serie de redes neuronales en forma dedos variables: relevancia y riesgo. Este modo trata de realizar funciones quenormalmente son ejecutadas por operador, relevando ası parte de las tareasy reduciendo la carga de trabajo. Ademas, se incorpora la herramienta deteletransporte para el movimiento dentro del escenario de la mision.
Los efectos de la realidad virtual y la componente predictiva se han medidoen un conjunto de experimentos efectuados sobre 24 operadores, compa-rando la interfaz de realidad virtual (predictiva y no predictiva) con unainterfaz convencional (tambien en modo predictivo y no predictivo). En di-chas pruebas, se asignaron 2 interfaces de las 4 posibles a cada operadorpara la monitorizacion de 8 misiones distintas, de forma que no se repitie-
Figura 2: Interfaz de monitorizacion
ra ningun conjunto interfaz-mision-(orden de uso) en los 24 experimentos.La carga de trabajo y conciencia de situacion fueron evaluados mediantecuestionarios SAGAT y NASA-TLX, con un total de 20 preguntas sobre lamision en cada interfaz, mas una asignacion de nivel de cada una de las6 variables que determinan la carga de trabajo (exigencia mental, fısica ytemporal, esfuerzo, rendimiento y frustracion). El analisis de los resultadospermite afirmar con un nivel de significancia del 95 % que las interfaces derealidad virtual superan a las convencionales en conciencia de la situacion,rendimiento y esfuerzo. Ademas, 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 monitorizacion del bra-zo robotico Kinova Jaco2 (estado de las articulaciones, localizacion del efec-tor, acciones sobre su entorno...) como el comandado del mismo (medianteel envıo de metas al efector moviendo una esfera de comandado), figura3. Ademas, se ha abordado con exito la conexion bilateral entre ROS yUnity mediante la herramienta RosBridge, mejorando los codigos existen-
tes y aportando nuevos tipos de mensajes que se pueden intercambiar. Lasprimeras pruebas con operadores muestran las cualidades de esta interfaz:la transmision de informacion espacial, el sistema de comandado intuitivoy la operacion en condiciones de seguridad.
Figura 3: Muestra de la interfaz de comandado
En resumen, el proyecto parte de dos objetivos principales: el desarrollode una interfaz de monitorizacion para misiones multi-robot y una interfazde control para un robot manipulador. En el proceso para alcanzar dichosobjetivos se han disenado escenarios, implementado modelos y creado in-teracciones en realidad virtual con Unity; desarrollado distintos modos decomunicacion entre Unity y ROS; creado un modo de comandado para elbrazo robotico en realidad virtual; y disenado y realizado un conjunto deexperimentos y pruebas para la evaluacion de las interfaces.
Ası, se ha conseguido aportar al estado del arte con interfaces inmersivas
de nueva generacion fuera del area de la robotica industrial. En la interfazde monitorizacion se logran unir componentes multimodales y predictivos,mientras que en la de comandado se consigue una interaccion con el robotreal mas alla del entorno de simulacion. Estos avances han abierto una grancantidad de lıneas de investigacion dentro del grupo, como el desarrollo deinterfaces de teleoperacion que integren informacion del entorno obtenidacon camaras 3D, muestren las trayectorias planificadas o muestren el brazorobotico montado sobre un robot movil.
Finalmente, este trabajo se ha llevado a cabo bajo una beca de colaboracionen el Departamento de Automatica. Los avances realizados han permitidouna aportacion significativa en tres publicaciones y la participacion en even-tos como las jornadas de puertas abiertas de la ETSII.
0.1. Palabras Clave
Robotica, Interfaz de Operador, Realidad Virtual, Robot Manipulador, Multi-robot, Inmersion, Prediccion, Carga de Trabajo, Conciencia de la Situacion(Situational awareness), Inteligencia Artificial.
0.2. Codigos UNESCO
1203 CIENCIA DE LOS ORDENADORES1203.04 INTELIGENCIA ARTIFICIAL1203.09 DISENO CON AYUDA DEL ORDENADOR1203.17 INFORMATICA1203.21 SISTEMAS DE NAVEGACION Y TELEMETRIA DEL ESPACIO1203.23 LENGUAJES DE PROGRAMACION1203.26 SIMULACION
1209 ESTADISTICA1209.03 ANALISIS DE DATOS1209.05 ANALISIS Y DISENO DE EXPERIMENTOS
3311 TECNOLOGIA DE LA INSTRUMENTACION3311.15 TECNICAS DE MANIPULACION A DISTANCIA
Abstract
Recent developments in immersive technologies have lead to new virtualreality tools with an extraordinary potential for robotic interface improve-ment. In particular, there are two fields where the use of virtual reality canbe especially beneficial.
The first field of interest is multi-robot missions, which provides operatorswith a great deal of challenges in terms of workload and situational aware-ness. In these kind of missions, operators must be able to receive data fromthe robots, extract relevant information, process it correctly, make decisionsbased on it and generate commands for the robots as soon as possible. The-refore, it is fairly common for them to get overwhelmed or miss importantpieces of information. Virtual reality interfaces provide a high level of im-mersion, which facilitates the comprehension of key facts about the mission.This increases the operator’s situational awareness in a natural, effortlessmanner.
The second field that stands out is robot teleoperation, particularly whencomplex actuators are involved. Virtual reality is able to immerse an opera-tor into the robot’s workspace, providing information about the tasks andallowing for an intuitive and precise control of the robot’s movements.
In light of the above mentioned, this project was targeted towards the designand implementation of two virtual reality interfaces: a monitoring interfacefor multi-UAV missions, and a teleoperation interface for a 6-degrees-of-freedom robotic arm. In both cases, the system architecture followed thediagram shown in figure 4. All robots functioned within a ROS (RobotOperating System) framework, which allowed for their control using a com-puter with Linux. This computer was connected through TCP/IP sockets toa Windows terminal with Unity and Steam VR, a Unity plugin that enabledconnections with an HTC Vive headset.
The monitoring interface reproduced the scenario from a series of enemy-tracking/ fire-extinguishing missions carried out in 2016 at the University of
Figura 4: System architecture
Luxembourg. These missions involved two UAVs and an UGV, whose tele-metry and commands were thoroughly registered for future reproductions.Said interface allowed the user to follow the missions with relevant infor-mation shown visually and aurally (figure 5). Fires and enemies appeareddynamically, UAVs moved realistically and there was a series of additionalelements that provided relevant information about the mission state at alltimes. The interface included a predictive mode, which integrated informa-tion extracted from neural networks in the form of two variables: risk andrelevance. Furthermore, movement within the mission’s scene was allowedthrough a teleporting mechanism.
The effects of virtual reality and the predictive component were measuredin a series of experiments involving 24 operators, who compared one virtualreality interface (predictive or not predictive) with a conventional one (pre-dictive or not predictive). In each experiment two interfaces were assignedto each operator for monitoring two of the eight possible missions. Missionand interface assignment was carried out so that no combination interface-mission was repeated for any operator. Situational awareness and operatorworkload were measured through NASA-TLX and SAGAT questionnaires,with 20 questions about every mission and an evaluation of each of the 6variables that determine workload (mental, physical and temporal demand,effort, performance and frustration). An analysis of the results concluded
Figura 5: Monitoring interface
with a level of significance of 95 % that virtual reality interfaces improveconventional ones in terms of situational awareness, performance and ef-fort. Moreover, they show better results in the remaining field, although asignificant 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 commandingsphere) figure 6. Furthermore, a bilateral connection between Unity andROS has been successfully achieved through the RosBridge tool. Existingcodes have been improved, and new types of messages have been added tothe package. User trials have shown the advantages of this interface: howspatial information is transmitted, how intuitive the commanding system isand how it allows the operator to work in a perfectly safe environment.
In summary, the project was conceived with two main targets: the deve-lopment of a multi-robot monitoring interface and the development of ateleoperation interface for a robotic manipulator. Throughout the process
Figura 6: Teleoperation interface
of reaching said objectives, a series of environments have been designed,robot models have been implemented and virtual reality animations andinteractions have been created; different modes of Unity-ROS communica-tion have been developed; a virtual reality robot arm commanding methodhas been found; and a set of experiments and trials have taken place forinterface evaluation.
This has allowed for a number of contributions to the state of the art awayfrom the beaten path of virtual reality in industrial robotics. The monitoringinterface unites multimodal and predictive elements, while the commandinginterface enables a real human-robot interaction. This progress has lead tonew research lines in the department such as the development of teleopera-tion interfaces that integrate environmental information obtained througha 3D camera and show the robot’s area of manipulability, or its planned
trajectories.
To conclude, this work has taken place under a fellowship in the Deparmentof Automation of ETSII UPM. Throughout the research made for this pro-ject, a significant contribution to three papers has been made, and it hasallowed participation in events such as the ETSII open day.
0.3. Keywords
Robotics, Operator Interface, Virtual Reality, Robotic Manipulator, Multi-robot, Immersion, Prediction, Workload, Situational Awareness, ArtificialIntelligence.
0.4. UNESCO Codes
1203 COMPUTER SCIENCE1203.04 ARTIFICIAL INTELLIGENCE1203.09 COMPUTER-ASSISTED DESIGN1203.17 INFORMATICS1203.21 NAVIGATION AND SPACE TELEMETRY SYSTEMS1203.23 PROGRAMMING LANGUAGES1203.26 SIMULATION
1209 STATISTICS1209.03 DATA ANALYSIS1209.05 DESIGN AND ANALYSIS OF EXPERIMENTS
3311 INSTRUMENTATION TECHNOLOGY3311.15 TELECHIRIC TECHNIQUES
Indice general
0.1. Palabras Clave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
0.2. Codigos UNESCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
0.3. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
0.4. UNESCO Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Indice de figuras XVII
Indice de tablas XXI
1. Introduccion 11.1. Motivacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 52.1. Estudio de Interfaces para Monitorizacion y Teleoperacion 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 implementacion de Realidad Virtual . . . . . 15
2.3. Estudio de Recursos de Comandado . . . . . . . . . . . . . . . . . . . . 17
2.4. Aportaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3. Herramientas de Desarrollo 193.1. Herramientas Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Elena Pena Tapia xiii
INDICE GENERAL
3.1.1. Robots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.1.1. Brazo Kinova Jaco2 . . . . . . . . . . . . . . . . . . . . 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. Comunicacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1. Nodo Original . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2. RosBridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4. Desarrollo 314.1. Proceso de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1. Familiarizacion con herramientas . . . . . . . . . . . . . . . . . . 31
4.1.1.1. Teletransporte . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.2. Monitorizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2.1. Definicion de las misiones . . . . . . . . . . . . . . . . . 33
4.1.2.2. Creacion 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. Monitorizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2. Comandado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5. Experimentacion y Pruebas 515.1. Monitorizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2. Comandado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6. Resultados 596.1. Monitorizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.1.1. Carga de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.1.2. Conciencia de la Situacion . . . . . . . . . . . . . . . . . . . . . . 61
6.1.3. Evaluacion de los usuarios . . . . . . . . . . . . . . . . . . . . . . 63
6.2. Comandado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
xiv ETSII UPM
INDICE GENERAL
7. Conclusiones y trabajos futuros 657.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.2. Lıneas futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3. Impacto ambiental, economico y social . . . . . . . . . . . . . . . . . . . 67
8. Planificacion y presupuesto 698.1. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.1.1. Costes directos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
8.1.1.1. Recursos humanos . . . . . . . . . . . . . . . . . . . . . 70
8.1.1.2. Recursos materiales . . . . . . . . . . . . . . . . . . . . 71
8.1.1.3. Recursos informaticos . . . . . . . . . . . . . . . . . . . 72
8.1.2. Costes indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.1.3. Coste total del proyecto . . . . . . . . . . . . . . . . . . . . . . . 72
8.2. Estructura de Descomposicion del Proyecto y Diagrama de GANTT . . 73
Bibliografıa 77
Elena Pena Tapia xv
INDICE GENERAL
xvi ETSII UPM
Indice de figuras
1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
2. Interfaz de monitorizacion . . . . . . . . . . . . . . . . . . . . . . . . . . v
3. Muestra de la interfaz de comandado . . . . . . . . . . . . . . . . . . . . vi
4. System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
5. Monitoring interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
6. Teleoperation interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
2.1. Ejemplo de puesto de control con interfaz convencional . . . . . . . . . . 6
2.2. Guante de realimentacion haptica . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Contribucion de la prediccion a interfaces multirrobot. . . . . . . . . . . 11
2.4. Interfaz de realidad virtual para entrenamiento de operarios. Vision glo-bal del entorno virtual (izq.) y vision en primera persona (der.). Muestradel uso de la interfaz (abajo) . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Sistema de cirugıa robotizada con RA y guiado por movimientos de manos 14
2.6. Gafas de realidad mixta Microsoft Hololens . . . . . . . . . . . . . . . . 15
2.7. Extremos en sistemas de RV. Izq: sistema con gafas mas base movil de6 g.d.l. Dch: entorno “inmersivo” con proyeccion de vıdeos en las 6 carasdel cubo [1]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2. Imagen del Jaco2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Elementos del sistema HTC Vive . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Ilustracion del funcionamiento del sistema lighthouse . . . . . . . . . . . 23
3.5. Diagrama de los mandos Vive (developer.viveport.com) . . . . . . . . . . 24
3.6. Diagrama de los elementos basicos de ROS . . . . . . . . . . . . . . . . 25
3.7. Ejemplos de posibles Assets de Unity . . . . . . . . . . . . . . . . . . . . 26
3.8. Recordatorio de la arquitectura del sistema . . . . . . . . . . . . . . . . 27
4.1. Capturas del juego desarrollado en RV . . . . . . . . . . . . . . . . . . . 32
Elena Pena Tapia xvii
INDICE DE FIGURAS
4.2. Diferentes mecanismos de teletransporte . . . . . . . . . . . . . . . . . . 33
4.3. Teletransporte en la interfaz de monitorizacion . . . . . . . . . . . . . . 34
4.4. Misiones multi-robot llevadas a cabo en Luxemburgo en 2016 y recreadasvirtualmente 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 evaluacion para relevancia y riesgo . . . . . . . . . . . . . . 39
4.9. Errores de prediccion de redes neuronales . . . . . . . . . . . . . . . . . 40
4.10. (arriba) Evaluacion del operador vs. prediccion 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. Diferenciacion 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, evolucionvista en Rviz (ROS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5. (1) Posicion inicial, envıo de meta con esfera de comandado.(2) Posicionfinal, 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 bloquesde interfaces (der.). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1. Ejemplo de como quedarıa el brazo montado sobre el robot Summit . . 67
8.1. Costes directos totales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
8.2. Evolucion del coste laboral por hora en el sector industrial, fuente:http://www.ine.es/jaxiT3/Tabla.htm?t=11219. . . . . . . . . . . . . . . 70
xviii ETSII UPM
INDICE DE FIGURAS
8.3. Coste de recursos humanos . . . . . . . . . . . . . . . . . . . . . . . . . 71
8.4. Coste de recursos materiales amortizables . . . . . . . . . . . . . . . . . 71
8.5. Coste de recursos materiales consumibles . . . . . . . . . . . . . . . . . 71
8.6. Coste de recursos informaticos . . . . . . . . . . . . . . . . . . . . . . . 72
8.7. Costes indirectos totales . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8.8. Coste total del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
8.9. EDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
8.10. Diagrama de GANTT del trabajo . . . . . . . . . . . . . . . . . . . . . . 75
Elena Pena Tapia xix
INDICE DE FIGURAS
xx ETSII UPM
Indice de tablas
2.1. Problemas asociados a interfaces convencionales . . . . . . . . . . . . . . 7
2.2. Problemas asociados a factores humanos en misiones multirrobot . . . . 8
2.3. Recopilacion de interacciones multimodales . . . . . . . . . . . . . . . . 10
2.4. Estudio de gafas de RV . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Resumen de resultados de los experimentos . . . . . . . . . . . . . . . . 59
6.2. Comparacion de las 4 interfaces (diferencias significativas en negrita). . 62
6.3. Resultados SAGAT (diferencias significativas en negrita). . . . . . . . . 64
Elena Pena Tapia xxi
INDICE DE TABLAS
Siglas y Acronimos
API: Application Programming Interface (Interfaz de Programacion de Aplicaciones)ANOVA: ANalysis Of VAriance (Analisis de la Varianza)EDP: Estructura de Descomposicion del ProyectoGRV: Gravity Referred View (Vista Referenciada con Gravedad)IAI: Interfaz Adaptativa InteligenteIC: Interfaz ConvencionalICP: Interfaz Convencional PredictivaIP (direccion): Internet Protocol (Protocolo de Internet)IRV: Interfaz de Realidad VirtualIRV: Interfaz de Realidad Virtual PredictivaHMD: Head Mounted Display (Display en forma de casco)LED: Light-Emitting Diode (Diodo Emisor de Luz)NASA-TLX: NASA Task Load Index (Indice de Carga de Tareas)OMPL: Open Motion Planning Library (Librerıa Abierta de Planificacion de Movimientos)RA: Realidad AumentadaRM: Realidad MixtaRN: Red NeuronalROS: Robot Operating System (Sistema Operativo de Robots)RV: Realidad VirtualSAGAT: Situational Awareness Global Assessment Technique (Tecnica Global de Evaluacionde la Conciencia de la Situacion)SGI: Silicon Graphics InternationalTCP/IP: Transmission Control Protocol/Internet Protocol (Protocolo de Control de Transmi-sion por Internet)TFG: Trabajo de Fin de GradoUAV: Unmanned Air Vehicle (Vehıculo Aereo No Tripulado)UGV: Unmanned Ground Vehicle (Vehıculo Terrestre No Tripulado)URDF: Unified Robot Description Format (Formato Unificado de Descripcion de Robots)XML: Extensible Markup Language (Lenguaje de Marcas Extensible)
xxii ETSII UPM
Capıtulo 1
Introduccion
1.1. Motivacion
Los 50 de Fukushima. Con este nombre se conoce a un grupo de trabajadores dela central nuclear de TESCO, en Japon. Cuando un tsunami asolo la costa japonesaen 2011, se produjo el fallo de multiples reactores, poniendo en peligro la integridadde la zona. A pesar de conocer los elevados niveles de radiacion que los rodearıan,Los 50 de Fukushima se quedaron en la central para intentar mitigar los danos. Elgrupo se componıa fundamentalmente de ingenieros y trabajadores cualificados, losunicos con conocimientos para responder ante el desastre. Estas personas decidieronrenunciar a sus vidas pero, en la actualidad, no son tratados como heroes. Ademas delas consecuencias negativas sobre su salud, deben enfrentarse al rechazo y aislamientosocial de las poblaciones que rodean la central.
En estas situaciones inesperadas y peligrosas, el uso de robots como sustitutos delos operadores humanos presenta una solucion ideal, aunque no exenta de retos. Apesar de que gran parte de los robots moviles son semi-autonomos, todavıa existenentornos y situaciones que requieren la intervecion de operadores humanos. Entre otrascondiciones, la operacion de robots a distancia requiere una interfaz que proporcionela informacion adecuada en la medida adecuada, que sea intuitiva y que reproduzcade una forma fiel la informacion obtenida del entorno. En concreto, lograr desarrollaruna interfaz user friendly, sencilla, universal y con una curva de aprendizaje reducidapresentarıa enormes ventajas, por la gran cantidad de aplicaciones que se podrıa extraerde ella.
La reciente aparicion en el mercado de las gafas de realidad virtual abre un universode posibilidades para la mejora de estas interfaces, al proporcionar un entorno inmersivo
Elena Pena Tapia 1
1. INTRODUCCION
y rico que ayuda al usuario a comprender mejor la situacion real. La intencion de esteTFG es explorar estas posibilidades, mediante el desarrollo de interfaces que permitanla monitorizacion y comandado de misiones con uno o mas robots de distintos tipos.
1.2. Marco de Desarrollo
Este proyecto se ha realizado dentro del departamento de Automatica de la EscuelaTecnica Superior de Ingenieros Industriales de la UPM. En concreto, dentro del grupode Robotica y Cibernetica (RobCib) del Centro de Automatica y Robotica (CAR) for-mado por la UPM y el CSIC. El TFG se enmarca dentro del proyecto PRIC (ProteccionRobotizada de Infraestructuras Crıticas), financiado por el Ministerio de Economıa yCompetitividad del Gobierno de Espana. Ademas, sirve de apoyo a la tesis doctoral’Multi-UAV Coordination and Control Interface’, que forma parte del proyecto SA-VIER (’Situational Awareness VIrtual EnviRonment’) de Airbus Defence & Space, encolaboracion con 5 universidades espanolas.
1.3. Objetivos
Con el fin de organizar el trabajo, se ha procedido a su descomposicion en objetivos,que pueden ser de caracter general o especıfico. A continuacion se vera una brevedescripcion 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 puedeimplicar el uso de interfaces de realidad virtual para el control y monitorizacion demisiones roboticas. Esto se realizara mediante la creacion y prueba de dos interfaces enUnity:
1. Interfaz de monitorizacion de misiones multi-UAV
2. Interfaz de control de un brazo robotico manipulador
1.3.2. Objetivos Especıficos
A un nivel mas detallado, se pueden establecer los siguientes objetivos especıficos:
Diseno de escenarios para misiones roboticas en Unity
2 ETSII UPM
1.4 Estructura de la Memoria
Implementacion de modelos de robots en Unity
Creacion de animaciones e interacciones en realidad virtual
Manejo de los robots y gestion de su informacion en el entorno ROS
Exploracion y desarrollo de comunicaciones entre ROS y Unity
Diseno de modos efectivos de visualizacion de la informacion
Desarrollo de modos de comandado para el brazo robotico manipulador
Diseno y realizacion de experimentos para evaluacion de las interfaces
1.4. Estructura de la Memoria
La memoria se estructura de la siguiente manera: El capıtulo 1 corresponde a laintroduccion. El capıtulo 2 presenta una recopilacion actualizada del estado del arte,en la que se analizan y comparan los avances actuales en el terreno de las interfaces y larealidad virtual, y se extraen los aspectos en los que se pueden mejorar. En el capıtulo3 se introducen las herramientas que se han empleado en el trabajo, mostrando suscaracterısticas principales y su papel en el sistema general. A continuacion, se procedea la explicacion en el capıtulo 4 de los elementos clave que intervienen en el desarrollo delas 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, yen el se analizan los resultados de los mismos. Finalmente, en los capıtulos 6 y 7 serecopilan las conclusiones del trabajo y los aspectos que atanen a su planificacion.
Elena Pena Tapia 3
1. INTRODUCCION
4 ETSII UPM
Capıtulo 2
Estado del arte
2.1. Estudio de Interfaces para Monitorizacion y Teleope-
racion de Robots
Las interfaces son uno de los elementos fundamentales de las misiones roboticas, es-pecialmente de las misiones multirrobot. Su influencia abarca los ambitos de recepcionde informacion y transmision de comandos. En este capıtulo se ha realizado un estu-dio comparativo de interfaces existentes en la literatura actual separandolas en cuatrocategorıas fundamentales: interfaces convencionales (2.1.1), multimodales (2.1.2), adap-tativas (2.1.3), e inmersivas (2.1.4). La idea de este estudio es localizar los aspectos masrelevantes para el desarrollo de interfaces de monitorizacion y control de robots, ası co-mo las debilidades existentes en interfaces actuales. Ası, se dispondra de una cantidadde informacion suficiente para cumplir el objetivo fundamental de este trabajo, el desa-rrollo de una interfaz inmersiva con realidad virtual.
2.1.1. Interfaces Convencionales
En la actualidad existen numerosos medios de control para la teleoperacion de ro-bots, desde dispositivos moviles como tablets o smartphones [2] hasta paneles de controlcon joysticks, volantes e incluso pedales. Las estaciones de control tıpicas incluyen lossiguientes elementos [3]:
1. Informacion sensorial de los robots
2. Ordenes y comandos mandados a los robots
3. Estado actual de los robots (baterıa, posibles fallos del sistema...)
Elena Pena Tapia 5
2. ESTADO DEL ARTE
4. Estado actual de las tareas
5. Mapas y elementos para la navegacion
La imagen 2.1 muestra un ejemplo de interfaz de telecontrol portatil con los 5elementos mencionados anteriormente. Como se puede observar, estas interfaces puedenllegar a resultar bastante complejas y aparatosas. Ademas, cabe destacar que el disenode las interfaces depende del tipo de robot, y en la actualidad es complicado encontrardesarrollos funcionales para multiples robots heterogeneos.
Figura 2.1: Ejemplo de puesto de control con interfaz convencional
El rendimiento en misiones que requieren el telecontrol de robots suele estar com-prometido por una serie de problemas asociados tanto a factores tecnologicos como afactores humanos. En muchos casos, la teleoperacion se convierte en una tarea difıcil,porque el procesamiento de los estımulos percibidos se encuentra desacoplado del en-torno fısico, causando problemas como una percepcion incorrecta de la escala mision[4]. Otras dificultades asociadas a factores tecnicos se encuentran clasificadas en la tabla2.1, en la que se muestran las principales tareas afectadas por cada problema y posiblessoluciones de acuerdo con [3]. Se puede observar que gran parte de estos problemas sepueden solucionar implementando una interfaz inmersiva en realidad virtual como lapropuesta en este trabajo.
En el caso concreto de misiones multirrobot, se suele recurrir mayoritariamente a uncontrol por supervision en lugar de teleoperacion. En estos casos, suelen prevalecer losproblemas asociados a factores humanos como el exceso de carga de trabajo o la faltade conciencia de la situacion (situational awareness) [6], terminos que se definiran masadelante en este apartado. La tabla 2.2 muestra una recoleccion de problemas asociados
6 ETSII UPM
2.1 Estudio de Interfaces para Monitorizacion y Teleoperacion de Robots
Cuadro 2.1: Problemas asociados a interfaces convencionales
Problema Tareas afectadas Soluciones propuestas
Campo visual limitado Deteccion, guiado Camaras 360/ multicamara +
interfaz inmersiva
Falta de Orientacion Navegacion, guiado Uso conjunto de mapas fijos y
relativos al robot, GRV (vista
referenciada con gravedad [5])
Percepcion contextual in-
correcta
Telemanipulacion Multiples camaras y pan-
tallas, vision exocentrica y
egocentrica
Percepcion de profundidad
incorrecta
Guiado y telemanipula-
cion
Realidad Virtual
Imagen de vıdeo degradada Percepcion de entorno Interfaces con elevados fps
Periodo de latencia Percepcion de entorno Interfaces predictivas
a factores humanos, con sus consecuencias y un posible metodo de deteccion.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 devista de la experiencia del operador [7]. Sin embargo, un estudio completo de la cargade 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 esfuerzofısico y mental [9]. En tests como el NASA-TLX, se suelen determinar 6 variablesrelativas a la carga de trabajo: exigencia mental, fısica, temporal, esfuerzo, rendimientoy frustracion.
Por su parte, la conciencia de la situacion se puede definir en tres niveles. El primernivel corresponde a la percepcion de elementos del entorno en un contexto espacial ytemporal; el segundo nivel corresponde a la comprension de su significado; y el terceroconsiste en ser capaz de proyectar su estado hacia el futuro [10]. Esto quiere decir quelos operadores, ademas de ser conscientes en todo momento de las posiciones de losrobots, deben conocer su razon de ser en el contexto de la mision y su potencial deevolucion en el futuro.
Las consecuencias de niveles inadecuados de carga de trabajo y conciencia de lasituacion, como se puede ver en la tabla 2.2, son fundamentalmente errores e ineficien-cias. El papel de las nuevas interfaces es clave para solucionar estos problemas. Las
Elena Pena Tapia 7
2. ESTADO DEL ARTE
Cuadro 2.2: Problemas asociados a factores humanos en misiones multirrobot
Problema Consecuencia Deteccion
Exceso de carga de trabajo Ineficiencia y
errores
Examen psicologico.
Tests (NASA-TLX)
Falta de conciencia de si-
tuacion
Ineficiencia y
errores
Examen de acciones y
rendimiento. Tests (SA-
GAT)
Estres y ansiedad Errores Variables fisiologicas
(frecuencia cardiaca,
sudoracion...). Tests
(NASA-TLX)
Falta/exceso de confianza Errores Estudio de reacciones.
Encuesta
posibles mejoras son diversas, desde la seleccion de la informacion mas relevante encada momento hasta la adicion de nuevos tipos de interacciones, como pueden ser lasinteracciones multimodales o la realidad virtual.
2.1.2. Interfaces Multimodales
El concepto de interaccion humano-robot multimodal hace referencia a la ’interac-cion con el entorno fısico y virtual a traves de modos de comunicacion naturales’ [11],es decir, aquellos que implican los cinco sentidos humanos (vista, oıdo, olfato, gustoy tacto) [12]. En otras palabras, la interaccion multimodal permite una comunicacionmas comoda con los sistemas automatizados a traves de interfaces de usuario.
En el ambito de las interfaces para monitorizacion y control de uno o mas robots,la multimodalidad permite la resolucion de algunos de los problemas mas habitualesque suelen surgir: un campo visual limitado, una percepcion de profundidad degradada,problemas de orientacion, etc [3].
Las mejoras asociadas a interfaces multimodales tienen lugar a dos niveles. Por unlado, permiten aumentar el rendimiento de los operadores complementando la infor-macion visual o dirigiendo la atencion del usuario hacia variables clave de la mision.Por ejemplo, la adicion de informacion auditiva produce un aumento de la concienciade situacion en operadores, segun [13]. En concreto, la adicion de sonidos puede trans-
8 ETSII UPM
2.1 Estudio de Interfaces para Monitorizacion y Teleoperacion de Robots
mitir la localizacion o la velocidad de los robots, llamar la atencion sobre alarmas odestacar eventos de la mision. En entornos ruidosos el uso de interacciones tactiles ohapticas puede relevar la funcion del audio [14]. La realimentacion haptica tambienpuede resultar util en la teleoperacion de robots manipuladores o quirurgicos, dadoque la transmision de fuerzas ficticias ayuda a mejorar la inmersion y percepcion delentorno. En la literatura existen diversas implementaciones de este tipo de interaccion,como la mostrada en la figura 2.2 [15].
Figura 2.2: Guante de realimentacion haptica
A nivel de comandado, los comandos multimodales como el uso de voz, tacto ygestos se estan implementando con la idea de alcanzar interacciones simples, rapidasy naturales entre operadores y robots [16]. Existen numerosos ejemplos de comanda-do de misiones multi-robot mediante comandos de voz [17], gestos manuales [18], ocombinaciones de gestos faciales y de manos [19].
La tabla 2.3 recopila las interacciones multimodales mas relevantes de acuerdo con[3], y muestra ejemplos de su implementacion presentes en la literatura actual.
2.1.3. Interfaces Adaptativas
El objetivo de las interfaces adaptativas es proporcionar la informacion necesariapara la toma de decisiones dentro del contexto de una mision de forma que la velocidad,precision, grado de comprension coordinacion y carga de trabajo de los operadores sevea mejorada [38]. Con tal fin, se recurre a la integracion de algoritmos de minerıade datos y machine learning. Estos algoritmos son capaces de relevar al operador endeterminadas tareas, como la deteccion de informacion relevante, y de esta manera
Elena Pena Tapia 9
2. ESTADO DEL ARTE
Cuadro 2.3: Recopilacion de interacciones multimodales
Interaccion Aporte Ejemplo
(ref.)
Uso de audio Buen complemento de feedback visual, llamada de
atencion ante alertas, aumenta percepcion de entorno
y puede reducir carga de trabajo.
[20], [21],
[22]
Feedback
tactil
Llamada de atencion efectiva, util para dar informa-
cion sobre orientacion, posicion y velocidad, especial-
mente eficaz en ambientes ruidosos con largos periodos
de vigilancia.
[23], [24],
[25]
Input haptico Util para proporcionar informacion sobre fuerzas, ideal
para tareas de manipulacion.
[26], [27]
Input auditivo
+ haptico
Mas practico que emplear interacciones de forma in-
dependiente. Compendia las ventajas de ambas.
[28], [29],
[30]
Comandos de
voz
Util en entornos moviles o cuando las manos del ope-
rador se encuentran ocupadas. Se pueden condensar
varios comandos en uno. Aligera carga de trabajo.
[31], [32]
Comandos ges-
tuales
Faciles de usar, gran rango de movimientos en el cam-
po visual de la camara.
[33], [34]
Comandos ges-
tuales + voz
Gran rango de interacciones naturales. Puede resultar
difıcil de procesar.
[35], [36],
[37]
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 informacion de las misones, aplicando los algoritmos mencio-nados. Estos modelos abarcan desde el comportamiento de los operadores hasta el delos robots, pasando por el tipo de tareas o las interacciones del entorno. Existen enla literatura una serie de directrices que determinan como debe ser el diseno de unainterfaz adaptativa [40]. Ademas, tambien se encuentran determinados los cuatro pasosque rigen el proceso de adaptacion:
1. Adquisicion de conocimientos (¿Que esta pasando?)
2. Atencion (¿Que adaptacion va a ocurrir?)
3. Razonamiento (¿Por que es necesaria?)
10 ETSII UPM
2.1 Estudio de Interfaces para Monitorizacion y Teleoperacion de Robots
4. Toma de decisiones (¿Como va a tener lugar?)
En el caso concreto de las misiones multi-robot, ya se ha visto que presentan unaserie de retos particulares a los operadores. Sobre todo, destacan los problemas asocia-dos a la carga de trabajo y la conciencia de la situacion. La figura 2.3 muestra comoun operador, cuando usa una interfaz convencional, debe recibir los datos, extraer lainformacion relevante, tomar decisiones, generar los comandos adecuados y mandarlosa los robots. Una posible solucion a este exceso de tareas consiste en delegar parte delas funciones en la propia interfaz.
Figura 2.3: Contribucion de la prediccion a interfaces multirrobot.
Un trabajo relacionado se puede encontrar en [41], donde se busca proporcionar alos robots habilidades propias de los humanos para percibir, entender y evitar riesgosdurante sus misiones. Para ello, el autor estudia la percepcion, cognicion y reacciontıpica humana frente a riesgos y desarrolla un marco de trabajo para aplicar estosconceptos a flotas de robots aereos.
La cantidad de datos generados en una mision multi-robot depende del numero ycomplejidad de los robots y las tareas involucradas. Esta informacion en bruto incluyelos estados de los robots (posicion, orientacion, velocidad, baterıa...) y las cargas de pago(medidas de los sensores, imagenes de las camaras, estado de los actuadores...). Cuandoel numero de datos es excesivo, es posible que los operadores no se vean capaces deprocesar toda la informacion para extraer las partes mas relevantes. Por ello, es posible
Elena Pena Tapia 11
2. ESTADO DEL ARTE
que cierta informacion pase inadvertida, como por ejemplo que tarea es mas crıtica,que robot requiere mas atencion o que situacion lleva asociado un mayor riesgo.
Una posible solucion a esta cuestion es lograr que la informacion importante se de-termine automaticamente a partir de los datos brutos extraıdos de la mision, generandoası una interfaz adaptiva. Por ejemplo, se puede realizar una simplificacion del proble-ma, 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 solonecesita prestar atencion a tres factores, reduciendo ası su carga de trabajo.
2.1.4. Interfaces Inmersivas
El proposito de las interfaces inmersivas es introducir virtualmente al operador en elescenario de la mision. Con este fin, se emplean multiples tecnlogıas como camaras 3D,gafas de realidad aumentada o gafas de realidad virtual. Mediante una reproduccionrica y detallada del escenario, se pretende conseguir una mejora de la conciencia de lasituacion 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 ultima la mas recientey una combinacion de las dos anteriores.
La realidad virtual muestra escenarios sintetizados digitalmente con elementos in-teractivos. Las interfaces RV suelen integrar dentro del mundo virtual representacionesde elementos reales como robots, objetivos, trayectorias, amenazas.... El nivel de in-mersion ha ido creciendo con la evolucion de las tecnologıas, partiendo de interfacesbasadas 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 realidadvirtual para entrenamiento de operarios en la programacion de robots de manufactura[52]. En el artıculo de Ruiz et al. [53], se comparan diferentes tipos de displays en elcontexto de misiones multi-UAV. Los experimentos demuestran que el uso de gafasde realidad virtual efectivamente mejora el conocimiento espacial de los operadores,aunque esta mejora tiene lugar en detrimento de la cantidad de carga de trabajo, quese ve aumentada. En lo referente a la teleoperacion en realidad virtual, cabe destacarel ambito de la robotica espacial, donde no se contempla la opcion de un control delos robots in situ. Ası, todos los avances en este area dependen de las tecnologıas deteleoperacion, que se enfrentan a importantes retos como la superacion de retardos enlas comunicaciones [54].
Las interfaces de realidad aumentada superponen sobre imagenes de vıdeo del en-
12 ETSII UPM
2.1 Estudio de Interfaces para Monitorizacion y Teleoperacion de Robots
Figura 2.4: Interfaz de realidad virtual para entrenamiento de operarios. Vision global
del entorno virtual (izq.) y vision en primera persona (der.). Muestra del uso de la interfaz
(abajo)
torno real elementos originados virtualmente. Estos elementos suelen incluir informa-cion relevante sobre las misiones en curso: posicion en mapas, elevacion del terreno,obstaculos en el camino, rutas a seguir u objetivos que se persiguen [55]. La mayorparte de las interfaces de RA desarrolladas se han aplicado a programacion de robotsmanipuladores ([56], [57]) y cirugıas robotizadas ([58], ver figura 2.5). No obstante, esposible encontrar en la literatura experimentos que muestran el potencial de la reali-dad aumentada en el contexto de las misiones roboticas. En [59] se utiliza una interfazde RA para analizar misiones multirrobot; y el experimento de [60] compara el rendi-miento de los operadores encontrando objetivos con interfaces convencionales y de RA.Los participantes encontraron un mayor numero de objetivos con el segundo tipo deinterfaz. Otros trabajos incluyen relieves en 3D, mapas donde aparecen las imagenesde vıdeo captadas por los diferentes robots o interfaces dibujan las trayectorias de losrobots ([61],[62]).
Finalmente, la realidad mixta combina elementos de RA y RV creando nuevos es-cenarios 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 programacion de robots industriales [63],
Elena Pena Tapia 13
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 evolucion natural de la RA. Aun ası, la RM posee un enormepotencial para aplicaciones en el terreno de la robotica [64], gracias a la aparicion deherramientas como las gafas Microsoft Hololens, mostradas en la figura 2.6.
14 ETSII UPM
2.2 Estudio de Recursos para implementacion de Realidad Virtual
Figura 2.6: Gafas de realidad mixta Microsoft Hololens
2.2. Estudio de Recursos para implementacion de Reali-
dad Virtual
El reciente desarrollo de sistemas de inmersion a lo largo de las ultimas decadas haampliado los recursos existentes para la mejora del rendimiento en misiones roboticas.Los primeros intentos de desarrollo de una estructura basada en realidad virtual seencontraban obstaculos como la falta de hardware especializado y la falta de estan-darizacion de sistemas de seguimiento, motores de juego, etc. Los primeros sistemasde RV como VE [65] y Flow VR [66] se encontraban atados a sistemas hardware ylibrerıas especıficas (por ejemplo, hardware SGI o librerıas OpenGL). El soporte paralos sistemas de seguimiento y otros inputs estaba limitado, y era complicado manejardistintas tecnologıas de RV (todavıa no estaba extendido el concepto de gafas de reali-dad virtual) con distintas estructuras de representacion digital (rendering structures)[1].
La imagen 2.7 muestra algunos de los retos que se han encontrado al intentar desa-rrollar un estandar efectivo para software y middleware en RV. La imagen de la izquierdamuestra un sistema de realidad virtual basado en gafas (HMD) que utiliza una basemovil para aportar sensacion de movimiento paralelamente al vıdeo que se muestra enla pantalla de las gafas. Aunque existen herramientas como rviz de ROS que permi-ten mostrar simulaciones del moviminto del robot en distintos entornos, rviz carece dela infraestructura necesaria para integrar con facilidad seguimiento del usuario, basesmoviles y demas.
Es por este motivo que, a nivel de software/middleware se ha optado por el disenode interfaces inmersivas aprovechando las caracterısticas que prestan los motores dediseno de videojuegos. Programas como Ogre [67] o Unity [68], gracias a la utilizacionde plugins y librerıas externas, permiten la inclusion de multiples pantallas, sistemas de
Elena Pena Tapia 15
2. ESTADO DEL ARTE
Figura 2.7: Extremos en sistemas de RV. Izq: sistema con gafas mas base movil de 6 g.d.l.
Dch: entorno “inmersivo” con proyeccion de vıdeos en las 6 caras del cubo [1].
seguimiento, motores de fısica, generacion de audio, bases moviles.... Este software sueleproporcional herramientas de edicion y programacion de scrcipts y otros mecanismosque permiten extender la infraestructura basica del motor de juego.
Por otro lado, a nivel de hardware se ha producido un avance considerable graciasal ”boom”de los sistemas de visualizacion de realidad virtual. El abanico de gafasde realidad virtual presente en el mercado es amplio [69], y se puede dividir en doscategorıas principales: moviles y dedicadas. La tabla 2.4 muestra una clasificacion delas gafas de realidad virtual mas populares.
Cuadro 2.4: Estudio de gafas de RV
Nombre Tipo Hardware Necesario
Sony PlayStation VR Dedicada PlayStation 4
HTC Vive Dedicada PC
Oculus Rift Dedicada PC
Google Daydream View Movil Telefono compatible con Daydream
Samsung Gear VR Movil Ultimos modelos Samsung Galaxy
Homido VR Movil Telefonos Android e iOS
FreeFly VR Movil Telefonos Android e iOS
Google Cardboard Movil Telefonos Android e iOS
Los sistemas moviles son de bajo coste, y se limitan a dividir la pantalla de untelefono movil con la ayuda de lentes para crear dos imagenes que, al superponerse,
16 ETSII UPM
2.3 Estudio de Recursos de Comandado
dan la sensacion de estar en 3 dimensiones. Si bien se estan comenzando a fabricartelefonos moviles exclusivamente disenados para la visualizacion en RV, todavıa no esposible encontrar ningun sistema de este tipo con el rendimiento mınimo requerido parael diseno de interfaces roboticas realistas. Entre otros motivos, presentan un reducidocampo de vision (por la mala calidad de las lentes); una baja persistencia (no sonrobustos ante movimientos rapidos de cabeza), un seguimiento de cabeza deficiente(dado que aprovechan los giroscopos integrados en el propio telefono) y carecen deseguimiento posicional o controles. Por ello, el diseno actual se limita al uso de sistemasde RV dedicada.
Como el PlayStation VR se encuentra anclado al uso de la consola PlayStation 4, alfinal las opciones restantes actuales son las gafas Oculus Rift y HTC Vive. Aunque susprestaciones son altamente similares, las HTC Vive poseen en este momento el modelomas moderno, y ofrecen ventajas como la posibilidad de movimiento libre dentro delentorno de trabajo.
2.3. Estudio de Recursos de Comandado
Los recursos de comandado en misiones para uno o varios robots tambien han sufridouna evolucion paralela a la de las interfaces.
Por un lado, podemos encontrar los recursos clasicos, empleados desde el inicio dela aparicion de robots teleoperados: paneles de control con interruptores, pulsadores yjoysticks. Ademas, cabe incluir dentro de esta seccion el aprovechamiento de mandoscomerciales de consolas como la Playstation o la Xbox, junto con los recursos asociadosa la teleoperacion mediante el uso de ordenadores: teclado y raton.
Por otro lado, con los avances de la tecnologıa se han ido incluyendo novedososrecursos como displays tactiles, guantes que realizan un seguimiento de las manos deloperador, sistemas de seguimiento de la mirada (particularmente usado para personascon discapacidad) [70], sistemas de reconocimiento de comandos de voz o sistemas dereconocimiento de gestos entre otros muchos.
En cuanto al comandado en realidad virtual, existe la limitacion que causa el bloqueodel campo visual del operador con las gafas. Esto implica que la utilizacion de recursosclasicos como un teclado y un raton se complica al no poder ver la representacion dedichos elementos en el mundo virtual. Esta limitacion se encuentra compensada con loscontroles incluidos en sistemas como el Oculus Rift o las HTC Vive, que permiten unaintegracion absoluta con el mundo virtual, dado que los mandos se ven de igual maneradentro y fuera de la RV.
Elena Pena Tapia 17
2. ESTADO DEL ARTE
Otras alternativas potenciales pasarıan por el uso de movimientos de cabeza, detec-tados por el sistema de seguimiento virtual, o la inclusion en el mundo virtual de unacamara que proporcione un apoyo visual para manejar elementos del mundo fısico.
La seleccion del recurso de mas apropiado depende tambien del nivel de comandadorequerido: en un comandado a bajo nivel conviene utilizar elementos que permitenla maxima maniobrabilidad e interactividad, en este caso, el uso de movimientos decabeza, manos o comandos de voz podrıa resultar apropiado. Un comandado a medionivel, como el envıo de waypoints, requiere de recursos que permitan el acceso a puntoslejanos; mientras que un comandado a alto nivel, como el envıo de tareas, se beneficiarıade la interaccion con elementos virtuales tales como menus o botones.
2.4. Aportaciones
Una vez estudiadas las interfaces existentes en el estado del arte, se pueden definirque aportaciones implica este trabajo segun los objetivos establecidos:
Se crearan dos interfaces inmersivas de nueva generacion (usando gafas de RV)fuera del ambito de la programacion de robots industriales.
Se uniran elementos inmersivos y multimodales en una interfaz de monitorizacion,que tambien puede incluir componentes adaptativos.
Se manipulara un robot real con una interfaz de realidad virtual, superando lasinterfaces de monitorizacion / simulacion empleadas hasta la fecha.
18 ETSII UPM
Capıtulo 3
Herramientas de Desarrollo
La figura 3.1 muestra una vision general del sistema implementado para el desa-rrollo de las interfaces en realidad virtual. Con tal fin, se han empleado diversas he-rramientas hardware y software. A nivel hardware, se encuentran los robots a moni-torizar/controlar, las gafas HTC Vive y los dos ordenadores involucrados. En cuantoal software, ha sido necesario manejar de forma simultanea dos ordenadores con dife-rentes sistemas operativos: uno en Linux con ROS (Robot Operating System), y otroen Windows con Unity3D y el plugin de Steam VR. En este capıtulo se explicaranen detalle las herramientas mencionadas y las comunicaciones entre las mismas, queaparecen representadas en forma de flechas.
Figura 3.1: Arquitectura del sistema
Elena Pena Tapia 19
3. HERRAMIENTAS DE DESARROLLO
3.1. Herramientas Hardware
3.1.1. Robots
Durante el desarrollo del proyecto se ha trabajado con tres modelos robots dife-rentes: un brazo manipulador (Kinova Jaco2 3.1.1.1), un robot movil terrestre (KUKAYoubot) y una pareja de UAVs Parrot AR.Drone 2.0. El primero se ha implementadodirectamente en la realidad virtual, mientras que los tres ultimos se han implementadode forma indirecta. El conjunto de misiones que empleaban los tres robots se llevo a ca-bo el abril de 2016 en Luxemburgo, todos los datos relevantes se grabaron en Rosbags, ya la hora de implementar la realidad virtual se utilizaron los datos de los Rosbags parareproductir las misiones reales (ver 3.2.1.1). Por ello, no se entrara en una descripciondetallada de sus caracterısticas en este apartado, aunque sı se hablara de los nodos ytopicos de ROS utilizados en apartados siguientes.
3.1.1.1. Brazo Kinova Jaco2
El robot manipulador Jaco2, fabricado por Kinova Robotics, posee 6 grados delibertad mas un efector final formado por tres dedos articulados (figura 3.2), lo que lodota de una gran maniobrabilidad. Puede soportar cargas de hasta 1,6 kg y su alcancees de 900mm. Este robot permite control de fuerza, lo que lo hace seguro para el trabajoen colaboracion con personas. La base es de aluminio extruido, y las diferentes partesarticuladas son de fibra de carbono.
El robot se puede controlar a traves de una conexion USB o Ethernet a un ordena-dor, aunque tambien posee un controlador embebido. En el ordenador se puede ejecutarla planificacion de trayectorias junto a otras tareas de alto nivel; mientras que el con-trolador embebido se encarga de ejecutar el control articular y, cuando sea necesaria,la cinematica inversa.
Para la planificacion de movimientos se utiliza el software de planificacion movilMoveIt!. Este software integra la Open Motion Planning Library(OMPL) [71], una li-brerıa de codigo abierto que implementa aloritmos de planificacion basados en muestreo:PRM, RRT, EST, SBL, KPIECE, SyCLOP, etc. Las funcionalidades de este softwareincluyen, entre otras, comprobacion de colisiones y percepcion 3D.
En concreto, para realizar el control de Jaco2 en el contexto de este TFG, se utilizoel algoritmo de planificacion autonomo RRT-connect (RRT indica Rapidly ExploringRandom Trees) previamente desarrollado [72]. El planificador funciona elaborando unarbol de exploracion de la siguiente forma:
20 ETSII UPM
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 mas cercano a qr entre los estados previos, y se denota comoqc.
3. Se tienen en cuentra las capacidades cinematicas del robot para encontrar unestado valido qm que surge de expandir qc en direccion a qr.
4. Se anade qm al arbol de exploracion.
Para configurar el robot en MoveIt! se emplea un fichero United Robot DescriptionFormat (URDF), que representa en lenguaje XML el modelo del robot, sus sensoresy su entorno. A partir del URDF, MoveIt! posee toda la informacion necesaria paraplanificar los movimientos. Para la generacion de URDF se parte de un fichero basicoproporcionado por el fabricante, al que se anaden posibles sensores adicionales juntocon la descripcion del entorno.
Una vez realizada la configuracion inicial, MoveIt! se comunica con el driver delbrazo para obtener la posicion de cada articulacion y demas parametros necesarios paraconocer es estado actual del robot. La configuracion final y la posicion del robot puedeser enviada a MoveIt! mediante una interfaz de control, o a traves de un mensaje de
Elena Pena Tapia 21
3. HERRAMIENTAS DE DESARROLLO
ROS. Una vez recibida la meta, se realiza la planificacion y se obtiene la trayectoria decada articulacion, que es enviada de vuelta al driver del robot, encargado de comunicarsecon el brazo y controlarlo.
3.1.2. Gafas HTC Vive
Las gafas de realidad virtual HTC Vive fueron originalmente concebidas con finesrecreativos, pero su versatilidad ha promovido la aparicion de nuevas aplicaciones masalla de los videojuegos. El sistema HTC Vive ofrece experiencias de realidad virtualadaptadas al espacio de una habitacion (modo roomscale) o restringidas a un usuariosentado (modo seated).
Los elementos principales del sistema se pueden observar en la figura 3.3. Las gafasper se reciben el nombre de HMD (Head Mounted Display). El HMD contiene dospantallas, una por ojo, que muestran imagenes en alta resolucion (1080x1200) con unratio de refresco de 90 Hz. Una salida de audio permite la conexion de auriculares paraaumentar el nivel de inmersion en el entorno virtual, gracias a la localizacion espacialdel sonido.
Figura 3.3: Elementos del sistema HTC Vive
El sistema de seguimiento de usuario utiliza dos estaciones base llamadas lighthouses(faros en ingles) emisoras de luz, y un gran numero de fotosensores colocados alrededordel HMD y los mandos. Las estaciones base son relativamente sencillas, con una serie dediodos LED estacionarios y una pareja de emisores de rayos laser. El funcionamiento delsistema es el siguiente: los diodos emiten aproximadamente 6 pulsaciones por segundo.Cada vez que una pulsacion LED tiene lugar, se inicia una cuenta que termina cuando
22 ETSII UPM
3.1 Herramientas Hardware
algun fotosensor interrumpe un rayo laser. De esta manera, relacionando la posicion delsensor con el momento de la deteccion del rayo, es posible calcular de forma precisa laposicion relativa respecto a las estaciones base, como muestra la figura 3.4. Esta sencillatecnica ofrece una precision sub-milimetrica en la localizacion y una latencia del sistemainferior a 22 ms [73]. Esta ultima propiedad resulta muy interesante, dado que el periodode latencia es uno de los factores principales que causan mareos y malestar asociado ala realidad virtual [74].
Figura 3.4: Ilustracion del funcionamiento del sistema lighthouse
Ademas del sistema de posicionamiento optico, las HTC Vive contienen sensoresadicionales como giroscopos, acelerometros e incluso una camara frontal que permitela deteccion de obstaculos en el area de trabajo.
Las HTC Vive incluyen una pareja de mandos con trackpads, gatillos y botones la-terales que permiten interactuar de forma sencilla e intuitiva con los objetos en realidadvirtual. Un diagrama de los principales componentes del mando se puede observar enla figura 3.5. Ademas de los botones, los mandos ofrecen la posibilidad de implementarrealimentacion haptica como parte de una intereaccion multimodal.
Elena Pena Tapia 23
3. HERRAMIENTAS DE DESARROLLO
Figura 3.5: Diagrama de los mandos Vive (developer.viveport.com)
3.2. Herramientas Software
3.2.1. ROS
ROS (Robot Operating System) [75] es un framework flexible que permite el desa-rrollo de software para robots. Se trata de una coleccion de herramientas, librerıas yconvenciones que pretenden simplificar la tarea de crear software robusto que abarqueuna amplia variedad de plataformas. En la ultima decada ROS se ha convertido en elmiddleware mas ultilizado para el desarollo de sistemas autonomos.
Aunque se ha llegado a implementar ROS en distintas plataformas hardware, elsoporte 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 unaplataforma de middleware estandarizada [1]:
1. No se encuentra asociado a ningun hardware especıfico ni modo de comunicacion(aunque suele utilizar TCP/IP).
2. Su software permite un desarrollo modular, gracias a la comunicacion indepen-diente con distintos agentes.
3. Ofrece soporte para una gran cantidad de robots y sensores
4. Se puede encontrar un gran numero de librerıas y herramientas de software yadesarrolladas para las aplicaciones roboticas mas comunes.
Dentro de ROS, el control de robots se modela como una coleccion de procesosasıncronos (nodos) que se comunica mediante mensajes dentro de los conocidos comotopicos. La imagen 3.6 muestra un esquema general del funcionamiento de ROS.
24 ETSII UPM
3.2 Herramientas Software
Figura 3.6: Diagrama de los elementos basicos de ROS
3.2.1.1. RosBags
El paquete RosBag contiene una serie de herramientas que permiten grabar losmensajes mandados dentro de distintos topicos para poder reproducirlos en cualquiermomento. Su alto rendimiento evita la perdida de sincronismo de los mensajes, y portanto se consigue que la reproduccion sea una copia exacta de la mision original.
La herramienta se maneja mediante la lınea de comandos de Linux ası como a travesde 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 validopara un gran numero de plataformas. Los juegos se desarrollan a partir de scripts, pro-gramados en Visual Studio o su propio editor (Mono Develop). Las principales ventajasde Unity para el desarrollo de sistemas inmersivos de monitorizacion/teleoperacion sonlas siguientes:
1. Soporte multiplataforma
2. Ofrece diversas opciones de programacion (C#, Javascript....)
3. Existen plugins para uso de hardware especıfico como Steam VR o MiddleVR
4. Posee un gran numero de librerıas propias y assets que facilitan el desarrollo
En Unity, la unidad basica de software es el GameObject. Un GameObject encapsulael diseno visual de un objeto y lo enlaza con el motor de juego, junto con la logica deinteraccion, animacion, control de frames, etc. Unity, como la mayorıa de programas de
Elena Pena Tapia 25
3. HERRAMIENTAS DE DESARROLLO
desarrollo de juegos, funciona a traves de frames, por lo que la necesidad de refrescarel display visual es crıtica y determina la totalidad de la infraestructura de software.Este modelo puede provocar dificultades cuando se intenta manejar en conjuncion consistemas de control de robots como ROS. No obstante, su ya mencionada flexibilidadmantiene a Unity como una de las mejores alternativas para el desarrollo de trabajoscon realidad virtual.
3.2.2.1. Assets
En Unity, un Asset constituye la representacion de cualquier elemento del proyecto.Un Asset puede proceder de un archivo creado fuera de Unity (modelo 3D, archivode audio, imagen...) o puede haber sido generado dentro del propio programa (unaanimacion, una textura renderizada...). La figura 3.7 muestra algunos de los archivosque 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 esla comunidad de desarrolladores que se encuentra detras, que con herramientas como laAsset Store permiten la descarga de paquetes de Assets ya configurados, que permitenel ahorro de una gran cantidad de tiempo y trabajo con muy buenos resultados.
26 ETSII UPM
3.3 Comunicacion
3.2.2.2. Plugin de Steam VR
El plugin de Steam VR para Unity se encuentra disponible de manera gratuitaen la Asset Store, y proporciona todas las herramientas necesarias para el manejo delas principales gafas de realidad virtual, incluidas las HTC Vive. Este plugin gestionala conexion entre el hardware de las gafas y Unity de modo que el desarrollador solotiene que centrarse en el aspecto software de su aplicacion. Ademas, incluye una seriede paquetes que facilitan un modo Debug en 2D, para evitar la dependencia de lasgafas; ası como las interacciones basicas con el mundo virtual. Cabe destacar que en laactualidad el plugin de Steam VR solo es compatible con el sistema operativo Windows.
3.3. Comunicacion
Si se recuerda la arquitectura del sistema (figura 3.8), se observa que se requiereel uso de 2 ordenadores con sistemas operativos diferentes, uno en Linux con ROS yotro en Windows con Unity y Steam VR. Uno de los aspectos clave de este trabajo esel de la comunicacion de estos dos ordenadores. En un principio, durante el desarrollode la interfaz de monitorizacion, se opto por la creacion de un nodo de comunicacionservidor-cliente usando el protocolo TCP/IP (apartado 3.3.1). Sin embargo, este nodoresultaba poco eficiente para el desarrollo de la interfaz de comandado, que requerıauna corriente de mensajes bidireccional con el menor retardo posible, y que ademasmanejaba mensajes mas complejos. La alternativa a la que se recurrio en este segundocaso fue el aprovechamiento del paquete RosBridge, explicado en el apartado 3.3.2.
Figura 3.8: Recordatorio de la arquitectura del sistema
Elena Pena Tapia 27
3. HERRAMIENTAS DE DESARROLLO
3.3.1. Nodo Original
El nodo original de comunicacion entre ROS y Unity aprovecha que ROS se basa enel protocolo TCP/IP para el envıo de mensajes entre distintos nodos. Ası, se estableceuna conexion mediante WebSockets con el nodo de Unity como servidor y el de ROScomo cliente.
El funcionamiento en lıneas generales es el siguiente:
1. Se establece la conexion servidor (Unity) - cliente (ROS)
2. El nodo ROS se subscribe al topico del robot real que se desea comunicar a Unity.
3. El robot real publica la informacion buscada en el topico.
4. El nodo ROS recibe el mensaje, y lo transforma en una cadena de caracteresformada por campos y etiquetas.
5. Se produce el envıo del mensaje entre cliente y servidor.
6. El servidor confirma la recepcion del mensaje.
7. El script de Unity decodifica el mensaje y efectua las acciones oportunas.
Este metodo presenta la gran ventaja de ser relativamente sencillo de comprendere implementar cuando no se domina el entorno ROS, ya que solo requiere suscribirsea un topico y guardar la informacion recibida en un parametro. La parte de envıo demensajes se basa en conocimientos de sockets TCP/IP, y una vez efectuado dicho envıo,la interpretacion y acciones posteriores se codifican en C#. Este es el motivo por el quese opto por su empleo en el diseno de la interfaz de monitorizacion.
A pesar de sus ventajas, tambien presenta ciertas limitaciones. La primera, es querequiere el diseno de una codificacion para los mensajes que se envıan de ROS a Unity.En el caso de la interfaz de monitorizacion, se deseaban transmitir la informacion delos siguientes topicos:
Posicion del robot terrestre (/robot/pose)
Posicion del UAV1 (/ardrone1/pose)
Posicion del UAV2 (/ardrone2/pose)
Informacion de navegacion del UAV1 (/ardrone1/ardrone/navdata)
Informacion de navegacion del UAV2 (/ardrone2/ardrone/navdata)
28 ETSII UPM
3.3 Comunicacion
Los tipos de los mensajes utilizados eran geometrymsgs/Pose (posicion y orienta-cion como cuaternio) y ardroneautonomy/Navdata (datos como la baterıa o el estadodel dron), siendo el segundo caracterıstico del paquete del Parrot AR.Drone 2.0.
La segunda limitacion es la dificultad anadida que supone establecer una comuni-cacion bidireccional. Cuando los envıos de informacion se encuentran espaciados en eltiempo, esto resulta posible mediante el uso de timers y banderas. Pero las aplicacionesde realidad virtual requieren el manejo de una cantidad muy elevada de frames porsegundo, y por tanto los tiempos ocupados por la informacion enviada en ambas direc-ciones resultan complicada de gestionar de forma “manual”. Es en estos casos cuandoconviene recurrir a herramientas como el RosBridge.
3.3.2. RosBridge
En el apartado anterior se ha mencionado que dentro de ROS, el flujo de los mensajessigue un protocolo basado en sockets TCP/IP. Este protocolo es sofisticado, y permiteun transporte de datos seguro y eficiente entre los nodos asıncronos de ROS. Si bien seha visto que es posible crear comunicaciones directamente, cuando se trata de interfacesde teleoperacion, este manejo directo requiere una comprension mas profunda de lainfraestructura de ROS. Ademas, surgen una serie de problemas relacionados con losretardos y el manejo de los frames de Unity. Por ello, en aras de ahorrar problemas yun trabajo innecesario, se puede proceder a “importar” la parte interesante de ROS alentorno de Unity mediante el framework de RosBridge [76].
El componente RosBridge permite comunicar programas externos a ROS (e.g. Unity)con nodos de ROS de forma directa. Los mensajes estandar de ROS son convertidosen mensajes JSON que pueden ser enviados a traves de una interfaz web. RosBridgeestablece un protocolo de comunicaciones que permite suscribirse o publicar en un topi-co de ROS desde los nodos creados en programas externos. Ademas, incluye una capade comunicacion regida por WebSockets que permite que el agente externo acceda alentorno de ROS desde cualquier localizacion.
El proceso de comunicacion ROS-Unity consiste en una transmision de mensajescodificados como cadenas yaml (YAML Ain’t Markup Language) [77] a traves de Web-Sockets. Estas cadenas yaml podrıan ser tratadas de forma directa por los agentes deexterno, pero resulta mas comodo utilizar nodos JSON [78] para mapear dichas cadenasa objetos instanciados en el entorno de Unity.
Como se ha indicado anteriormente, la comunicacion entre RosBridge y Unity es bi-direccional. Rosbrigde recibe de Unity los mensajes de control, formados por comandosde movimiento y otras senales que controlan la ejecucion de la mision. Por otra parte,
Elena Pena Tapia 29
3. HERRAMIENTAS DE DESARROLLO
RosBridge envia de vuelta el estado del robot. Por ejemplo, con un robot manipuladorcomo el Jaco2, el estado consistirıa en la posicion de cada una de las articulaciones,medidas de los sensores y cualquier otra informacion que permita al operador adquirirun conocimiento adecuado de la situacion.
30 ETSII UPM
Capıtulo 4
Desarrollo
4.1. Proceso de desarrollo
El proceso de desarrollo se puede dividir en una fase inicial de familiarizacion conlas herramientas (4.1.1), el desarrollo de la interfaz de monitorizacion de misiones mul-tirrobot (4.1.2) y el desarrollo de la interfaz de comandado del brazo robotico(4.1.3).
4.1.1. Familiarizacion con herramientas
Las etapas iniciales del trabajo se dedicaron a la familiarizacion con el entornode desarrollo Unity3D, el meta-sistema operativo ROS y las gafas de realidad virtual.Para ello, ademas de la realizacion de numerosos tutoriales, se ideo un juego en 3D queponıa en practica los principales elementos necesarios para las interfaces: elementos devisualizacion, modos de interaccion con el entorno y metodos de teletransporte (figura4.1). La figura 4.2 muestra capturas de escenas de un tutorial en las que se pueden verlos distintos elementos.
4.1.1.1. Teletransporte
Las gafas HTC Vive poseen la ventaja de permitir el libre movimiento dentro delarea definida por las estaciones base. No obstante, cuando se disena en realidad virtualconviene implementar en todo momento un mecanismo de teletransporte para evitarmovimientos bruscos y accidentes.
Un mecanismo rudimentario de teletransporte, desarrollado en la etapa de familia-rizacion, consiste en el disparo de un rayo desde alguno de los mandos que, al entraren contacto con alguna superficie de la escena, traslada al jugador virtual a ese puntode forma inmediata.
Elena Pena Tapia 31
4. DESARROLLO
Figura 4.1: Capturas del juego desarrollado en RV
Una version mas avanzada serıa el mecanismo de teletransporte basado en el Assetde Steam VR. Este permite la definicion de zonas de acceso prohibido y permitidomediante layers, ası como la definicion de una trayectoria del laser mas vistosa y comodade utilizar. Ademas de areas de teletransporte, tambien se pueden definir puntos deteletransporte, que trasladan a una posicion fija programable. La figura 4.2 muestraejemplos de los dos modos de teletransporte implementados, y la figura 4.3 muestra laimplementacion del teletransporte en la interfaz de monitorizacion.
32 ETSII UPM
4.1 Proceso de desarrollo
Figura 4.2: Diferentes mecanismos de teletransporte
4.1.2. Monitorizacion
El diseno de la interfaz de monitorizacion se realizo con los datos extraıdos deuna serie de experimentos efectuados en el laboratorio del Interdisciplinary Centre forSecurity, Reliability and Trust (SnT) de la Universidad de Luxemburgo en abril de2016 [42], figura 4.4. Dichos datos incluıan un registro completo de la telemetrıa de losrobots, los comandos transmitidos y grabaciones en vıdeo de las 42 misiones efectuadas.a
4.1.2.1. Definicion de las misiones
El objetivo de las misiones a monitorizar era el control de dos robots aereos queejecutaban de forma alternativa tareas de deteccion/extincion de incendios y detec-cion/seguimiento de robots enemigos. El escenario, situado en una nave, consistıa enun espacio de 5,35 m x 6,70 m x 5,00 m en el que se podıan encontrar marcadoresindicando las posiciones de la base de los UAVs, un deposito de agua y fuegos conposiciones variables segun la mision. Las misiones de los UAVs incluıan las siguientestareas a repartir entre los robots:
Elena Pena Tapia 33
4. DESARROLLO
Figura 4.3: Teletransporte en la interfaz de monitorizacion
Sin Tarea: Tarea que precede al inicio
Inicio: Encendido y despegue del UAV
Vigilancia: El UAV recorre un area en zig-zag en busca de un fuego o intruso
Reconocimiento: El UAV sobrevuela puntos donde ha habido detecciones paraconfirmarlas
Carga: El UAV se dirige al deposito a por agua
Descarga: El UAV suelta el agua tomada del deposito para extinguir el fuego
Seguimiento: El UAV sigue al enemigo previamente detectado
Fin: Aterrizaje y apagado del UAV
Los robots involucrados en las misiones fueron dos UAVs Parrot AR.Drone 2.0 [79]y un robot terrestre (UGV) KUKA Youbot [80]. El operador se encargaba del manejode ambos drones a traves de una interfaz, mientras que el robot terrestre, consideradoun enemigo, funcionaba de forma autonoma y desconocida para el operador. La interfazde usuario permitıa el comandado del robot mediante tareas referidas en tiempo real,guardando la informacion en hojas de Excel para usos futuros.
La posicion y orientacion de los tres robots se determino mediante marcadores atraves del sistema de camaras infrarojas Optitrack [81]. De forma adicional, los UAVs
34 ETSII UPM
4.1 Proceso de desarrollo
Figura 4.4: Misiones multi-robot llevadas a cabo en Luxemburgo en 2016 y recreadas
virtualmente en Madrid en 2017.
ofrecıan un registro de su telemetrıa completa: estado, posicion y orientacion segunodometrıa; velocidades y aceleraciones lineales y angulares segun las lecturas de laIMU; nivel de baterıa y voltaje entregado al motor.
Finalmente, el framework de ROS permitio la integracion de todos los componentesde la mision, tanto hardware como software: los robots, el sistema Optitrack y la interfaz[75]. Toda la informacion quedo registrada en archivos ROSbag.
4.1.2.2. Creacion de la interfaz
El proceso de construccion de la interfaz comienza por la reproduccion a escala 1:1del escenario de los experimentos de Luxemburgo. Inicialmente se procedio a una copiaexacta del escenario real (figura 4.5), que poco a poco fue evolucionando a una versionmejorada con elementos adicionales (figura 4.6). Los elementos principales se explicaranutilizando como base la imagen 4.6, con el diseno definitivo.
Los elementos se pueden dividir en dos categorıas: estaticos y dinamicos. Dentro delos elementos estaticos se encuentra el suelo, con un diseno que ayuda a la orientacionespacial del usuario; las cuatro paredes de cristal que separan el escenario del entornoexterior; y el deposito de agua, que resulta otra referencia ultil para la orientacion en
Elena Pena Tapia 35
4. DESARROLLO
Figura 4.5: Escenario inicial vs real en RV
Figura 4.6: Escenario mejorado en RV
realidad virtual. Como elemento adicional se incluyo una plataforma de observacion(figura 4.6) que ofrece un punto de vista elevado para un mejor control de todos losagentes de la mision.
Por otra parte, se encuentran los elementos dinamicos: los dos UAVs, el UGV, losfuegos y los mandos de las HTC Vive, que se consideran parte activa de la interfaz.
Las posiciones y orientaciones de los tres robots se transmiten desde los ROSbagsa traves del nodo de comunicacion (ver apartado 3.3.1) y se traducen directamente enlos modelos de la interfaz. Ademas de la rotacion y traslacion, los UAVs incorporanel giro de sus helices para anadir realismo a la imagen, ası como una fuente con elsonido de los rotores, que resulta util para la localizacion y percepcion de la distanciacuando se encuentran fuera del campo visual del operador. Ademas, ambos robots estandotados de sendas pantallas translucidas en las que se muestra la tarea en curso juntocon el nivel de baterıa. La barra de baterıa interpola su tonalidad entre los valosresRGB extremos de verde y rojo de modo que se transmita una idea mas intuitiva delnivel de baterıa en cada momento. Estas pantallas contienen un script que hace que
36 ETSII UPM
4.1 Proceso de desarrollo
se encuentren apuntando en todo momento a la camara de las gafas, de modo que lainformacion se encuentra facilmente accesible en todo momento.
El robot terrestre, como ya se ha indicado, se mueve de acuerdo con la telemetrıade la mision en curso. Sin embargo permanece oculto en el escenario hasta el momentode su descubrimiento por alguno de los UAVs. El fuego sigue el mismo principio. Lostiempos de descubrimiento de ambos elementos se han determinado de forma empıri-ca comparando datos del comandado y los vıdeos de las misiones, y se encuentranregistrados en vectores de datos.
La implementacion del mecanismo de teletransporte en esta interfaz se ve mejoradacon respecto a desarrollos anteriores (4.1.1). El escenario de teletransporte se limita alespacio marcado por las paredes de cristal. Los gatillos de los mandos generan un laserparabolico al ser presionados, y el final de la parabola marca el destino del teletranspor-te. La forma parabolica permite un acceso mas comodo a todos los puntos del escenario,y su color cambia para marcar si la zona es accesible o no (rojo/ verde). Ademas, en elmomento del lanzamiento de la interfaz se lleva a cabo un pequeno tutorial de uso delteletransporte. Finalmente, el acceso a la plataforma de observacion se facilita con lainclusion de dos puntos de teletransporte en la pared, como muestra la figura 4.3.
Figura 4.7: Objetos que forman parte de la interfaz
La figura 4.7 muestra una captura de la jerarquıa de objetos que forman parte la in-terfaz. Los objetos “Directional light”, “Environment”, “Scenario’, “Reservoir”,“Walls”y “Platform” son elementos estaticos que constituyen el entorno de la interfaz. Por otrolado, los objetos contenidos en “Fleet” son los dos drones y el robot terrestre, elementosdinamicos. La imagen de la derecha muestra un desglose poco detallado de los elemen-tos que componen los robots y los drones. Los “FireManager” y “ROSConnector” son
Elena Pena Tapia 37
4. DESARROLLO
objetos vacıos que contienen scripts que gestionan el desarrollo del juego. En concreto,el FireManager se encarga de gestionar y sincronizar la aparicion de fuegos de acuerdoa la mision en curso; mientras que el ROSConnector gestiona la lectura de los excelsde datos (“ExcelReader”) y la conexion con ROS (“LuxCommunication”). El script“LuxCommunication” es tambien el encargado de gestionar los movimientos de todoslos elementos dinamicos guardados en los ROSBags. El componente “Predictor” mane-ja los focos/nubes de humo segun los datos extraıdos del Excel con el “ExcelReader”.Finalmente, los objetos “SteamVR”, “Player” y “Teleporting” son los que se ocupande las interacciones con el hardware y los mecanismos de teletransporte.
4.1.2.3. Componente predictiva
En el estado del arte se trataron los posibles efectos negativos sobre la carga detrabajo y conciencia de la situacion que produce el uso de interfaces convencionales enmisiones multirrobot. Por ello a la hora de disenar los experimentos de monitorizacion,se decidio aprovechar para evaluar de forma simultanea el impacto de dos recursos enel rendimiento del operador: la inmersion en realidad virtual y la adicion de elementospredictivos.
Ası, se procedio a la inclusion de un modo predictivo a la interfaz de monitorizacionen realidad virtual. Para ello, se determinaron dos variables predictivas con inteligenciaartificial: relevancia y riego. Ası, la interfaz predictiva incluye todos los elementos de laversion anterior ademas de dos nuevos elementos que simbolizan el riesgo y la relevanciaasociados a cada UAV. Estas dos variables se pueden definir de la siguiente forma:
Relevancia. Medida de la importancia del robot en determinadas situaciones dela mision. En este caso, la medida se expresa en forma de porcentaje, del 0 %(el robot no participa en la mision) al 100 % (la mision depende totalmente delrobot). La suma de las relevancias de los robots involucrados en la mision debeser el 100 % en todo momento.
Riesgo. Medida de los danos potenciales que el robot puede sufrir en determina-das situaciones de la mision. El riesgo tambien se mide en porcentaje, donde el0 % significa una seguridad absoluta y el 100 % corresponde a un accidente queya ha tenido lugar. En el caso del riesgo, la suma de todos los robots involucradosen la mision no tiene por que ser 100 % en todo momento.
El desarrollo de la componente predictiva se realizo segun los siguientes pasos:
38 ETSII UPM
4.1 Proceso de desarrollo
Figura 4.8: Criterios de evaluacion para relevancia y riesgo
1. Evaluacion del riesgo y relevancia de todas las misiones. Observacion devıdeos de las misiones y anotacion de los valores a lo largo del tiempo. Los criteriosorientativos de evaluacion de estas dos variables se muestran en la figura 4.8. Cabedestacar que esta evaluacion no resulta determinista, dado que entradas similarespueden producir diferentes valores de salida segun el criterio del operador.
2. Preparacion de las hojas de datos. Este paso conduce a la generacion de hojasde calculo asociadas a cada mision donde cada columna corresponde a una variablede la mision y cada fila marca un instante de tiempo definido, sumando un total de590 lecturas. Los datos recolectados de las misiones incluyen 101 variables entreprimarias (telemetrıa y baterıa), secundarias (tarea, distancia entre robots...) yvariables objetivo (relevancias y riesgos). Estas variables fueron sometidas a testsde correlacion mostrando una correlacion inversa absoluta entre las relevancias delos dos UAVs y bajas correlaciones entre el resto de variables (0.594 entre riesgos,±0,178 y ±0,395 entre riesgos y relevancias)
3. Entrenamiento de redes neuronales. Para el entrenamiento de las redes seutilizaron los datos de 8 misiones, con un algoritmo de back propagation imple-mentado en RapidMiner Studio 7.5. En total se generaron 16 redes neuronales:cuatro redes (capas 1,2,3,4) para cuatro variables (UAV1, UAV2, relevancia, ries-go).
4. Validacion de redes neuronales. Para la validacion se utilizaron los datos de8 misiones distintas a las de entrenamiento. La figura 4.9 muestra la media ydesviacion tıpica de los errrores en la prediccion de cada red neuronal. Se puede
Elena Pena Tapia 39
4. DESARROLLO
Figura 4.9: Errores de prediccion de redes neuronales
observar como la relevancia muestra un error superior al riesgo. Lo mas probablees que esta diferencia se deba a la naturaleza de ambas variables: la relevanciaoscila de 0 a 100 % con una media de 50 %, mientras que el riesgo se suele mantenerbajo el 20 % y su comportamiento denota una serie de picos. Se eligieron redes concuatro capas ocultas porque son las que muestran los mejores resultados con 3 delas 4 variables. La figura 4.10 muestra la comparacion de valores reales-prediccionpara las cuatro variables, ası como el error absoluto presente en las mismas. Lasredes son capaces de predecir las tendencias de las variables pero no llegan aanticipar los picos. Esto da lugar al mayor error de prediccion ya mencionado.
La comparacion de los errores de entrenamiento y validacion de las redes revela laexistencia del fenomeno de overfitting. En concreto, se puede observar que los errores deentrenamiento son 5 veces menores que los de validacion. No obstante, esto no suponeun problema a la hora de implementar la informacion en las interfaces, dado que losvalores no se utilizan de forma directa, sino a traves de umbrales. De este modo, cuandose detecta que la relevancia de un UAV es mayor que la del otro, la interfaz seleccionaese UAV como el mas relevante. Por parte del riesgo, solo se determina que existeriesgo cuando el valor de la variable supera el 50 %. Por ello, el error total de las redesneuronales, incluyendo falsos positivos y falsos negativos, no supera el 7.64 % (11.55 %en la relevancia del UAV 1, 5.1 % en el riesgo del UAV 1, 12.28 % en la relevancia delUAV 2 y 1,6 % en el riesgo del UAV 2). Este resultado se considera adecuado paraasumir un correcto funcionamiento de las interfaces.
Una vez obtenidos los valores de las predicciones, se registraron en hojas de excelsiguiendo el mismo formato que en las hojas de datos para el entrenamiento de las
40 ETSII UPM
4.1 Proceso de desarrollo
Figura 4.10: (arriba) Evaluacion del operador vs. prediccion de la red neuronal (RN).
(abajo) Errores de cada RN y medias de cada error.
Elena Pena Tapia 41
4. DESARROLLO
redes. Se incorporo un lector de excel capaz de importar los datos relevantes de lamision durante el lanzamiento de la interfaz.
La interpretacion de las dos variables predictivas se realizo de la siguiente forma,como se puede observar en la figura 4.11:
Relevancia. Se opto por representar la relevancia mediante un foco de luz queapuntara al dron mas relevante en cada momento, dado que solo puede ser unode los involucrados en la mision. El foco atrae la atencion del operador de formaintuitiva.
Riesgo. Para representar el riesgo, se establecio un umbral del 50 %, de modoque cada vez que alguno de los robots involucrados en la mision supere el umbralde riesgo, aparece una nube de humo sobre el robot que transmite la idea deamenaza o peligro inminente.
Figura 4.11: Interfaz de RV con componentes predictivos integrados
4.1.3. Comandado
La interfaz de comandado consiste en una integracion del brazo robotico manipula-dor en la realidad virtual. Esta integracion requiere una conexion entre el mundo realy el virtual. El mundo real se compone del robot manipulador y su espacio de trabajo,y esta dominado por Robot Operating System (ROS) (con MoveIt! integrado). ROS se
42 ETSII UPM
4.1 Proceso de desarrollo
ocupa de la planificacion y el control del robot. Por otro lado, el mundo virtual contienela interfaz de usuario, y se encuentra controlado por Unity y Steam VR.
4.1.3.1. Interfaz para el Jaco2
El desarrollo de interfaz de comandado comienza con la importacion del modelo delas piezas del robot en uno de los formatos compatibles con Unity3D. Para lograr unmovimiento realista del brazo es necesario importar las piezas por separado y realizarel ensamblado dentro del entorno de desarrollo. En este caso, se dispuso de las medidascontenidas en el archivo URDF del modelo para guiar con precision el montaje de todaslas articulaciones.
Cuando se importan modelos disenados por terceros, es comun encontrar orıgenesdesplazados y ejes de referencia intercambiados, de forma que no resultan intuitivos.Esto puede complicar mucho el manejo de los movimientos en el entorno virtual. Por estemotivo, se ha recurrido a la creacion de “piezas auxiliares”, es decir, objetos vacıos conla posicion y orientacion deseada para la articulacion. Una vez creados dichos objetos,se vinculan los modelos de las piezas, de forma que coincide la orientacion “visible” conla orientacion “programable”. La figura 4.12 muestra un ejemplo de como ayuda el usode piezas auxiliares. La pieza de la izquierda se encuentra referenciada con los ejes quecorresponden al modelo importado. Si se quisiera ensamblar con la pieza blanca tal ycomo muestra la figura de la derecha, serıa necesario girarla 90o en el eje y, lo que luegopodrıa dar problemas a la hora de calcular las rotaciones en angulos de Euler, ya quehabrıa que tener en cuenta un desfase de 90o en y. Aquı es donde entran en juego laspiezas auxiliares. Si se anida la pieza gris girada 90o a un objeto vacıo con rotaciones(x,y,z) = (0,0,0), se consiguen los ejes de referencia de la figura de la derecha con laorientacion correcta de la pieza.
El modelo del brazo se divide en un total de 10 piezas, como se puede ver en lafigura 4.13.
En el control del brazo intervienen dos scripts. El primero (”Inter”) se encargade definir la posicion del efector final del brazo a traves de una esfera con la que eloperador interactua. El segundo (”RealSenseViewer”), transmite la posicion deseadadel efector final al robot a traves del rosbridge, tal y como se explica en el apartado3.3.2. El software del brazo es el encargado del procesamiento de esta informacion y loscalculos para el control cinematico inverso, ası como la transmision de esta informaciona los actuadores de las distintas articulaciones.
La figura 4.14 muestra un esquema general de las comunicaciones entre el robot yUnity. Es posible observar como, una vez recibidos los comandos desde RosBridge, un
Elena Pena Tapia 43
4. DESARROLLO
Figura 4.12: Ejemplo de utilidad de piezas auxiliares
nodo intermedio se encarga de procesarlos y convertirlos en mensajes. Estos mensajesya pueden ser interpretados como ordenes de control validas para MoveIt!. El nodotambien envıa las senales necesarias para iniciar, detener o reiniciar el movimientodel brazo. MoveIt! procesa estos mensajes, realiza la planificacion de movimientos yenvıa las trayectorias articulares al controlador del robot. Este ultimo se encarga de lacomunicacion con el controlador embebido del robot y envıa de vuelta mensajes conel estado de las articulaciones. RosBridge manda este mensaje directamente a Unity,donde se procesa para ser manejado por el operador.
Una vez establecido el procedimiento de comunicacion, se anadieron una serie deelementos para enriquecer el escenario, y que quedara como en la figura 4.15.
44 ETSII UPM
4.1 Proceso de desarrollo
Figura 4.13: Diferenciacion de las 13 piezas del brazo
Figura 4.14: Esquema de comunicaciones del robot con el entorno Unity.
Elena Pena Tapia 45
4. DESARROLLO
Figura 4.15: Muestra del escenario final del brazo
46 ETSII UPM
4.2 Funcionamiento de las interfaces
4.2. Funcionamiento de las interfaces
4.2.1. Monitorizacion
Para la utilizacion correcta de la interfaz de monitorizacion es necesario seguir unaserie de pasos previos de configuracion:
1. Comprobar que el ordenador con Linux y el ordenador con Windows estan conec-tados a la misma red.
2. Introducir la direccion IP y el puerto del ordenador Windows en los apartadoscorrespondientes del script de Unity y el launcher del nodo de ROS.
3. Introducir el numero de mision en el lector de excel (para la componente predic-tiva) y el gestor de fuegos (figura 4.16).
4. Lanzar la interfaz en Unity.
5. Seleccionar si se desea mantener o quitar la componente predictiva (figura 4.16).
6. Lanzar el nodo de ROS.
Figura 4.16: Muestra de los pasos previos 3 y 5.
Una vez completados estos pasos, la interfaz se encuentra conectada a ROS y lis-ta para el visionado, que comenzara cuando se reproduzca el RosBag de la misioncorrespondiente.
Elena Pena Tapia 47
4. DESARROLLO
Dentro de la interfaz, el usuario se puede mover libremente por el escenario de lasmisiones, eligiendo el punto de vista que considere mas adecuado. El sonido estereo sepuede ajustar mediante los controles de las gafas, y ayuda a localizar los elementos enmovimiento.
Ambos mandos permiten teletransportarse dentro del escenario y subir a la plata-forma de visionado mediante los puntos de teletransporte. En los instantes posterioresal lanzamiento de la interfaz, los mandos comienzan a vibrar para llamar la atenciondel usuario y un pequeno indica la posicion del gatillo que hay que pulsar para lanzarla parabola de teletransporte, a modo de pequeno tutorial 4.17.
Figura 4.17: Indicadores en los mandos tras el lanzamiento de la interfaz.
4.2.2. Comandado
La interfaz de comandado es mas directa que la de monitorizacion. El unico pasoprevio que se requiere es la introduccion de la direccion IP y el puerto del ordenadorcon Linux en el apartado correspondiente del script de Unity, y la comprobacion de quela red es correcta.
Una vez establecida la conexion, y con el brazo en el modo adecuado, es posibleiniciar la teleoperacion. Para ello, basta con acercar el mando a la esfera de comandadoy presionar el gatillo para agarrar la esfera, que dirigira con su posicion y orientacionel extremo del brazo. Cabe destacar que el brazo tiene limitadas las posiciones quepuede alcanzar, y por tanto es posible que se intente mandar un destino sin respuesta.En caso de que esto suceda, conviene probar a modificar la orientacion de la esfera decomandado para intentar facilitar la llegada del brazo al punto deseado.
Para el comandado del manipulador se plantearon varios sistemas intuitivos y final-
48 ETSII UPM
4.2 Funcionamiento de las interfaces
mente se opto por una esfera con tres ejes. La esfera representa la posicion que tiene quealcanzar el efector del robot, mientras que los tres ejes definen la orientacion que debeadquirir el mismo. Cuando la esfera esta en el efector, el robot permanece en reposo.En cualquier momento, el operador puede agarrar la esfera, desplazarla por la escena ysoltarla en otra localizacion. Cuando el operador suelta la esfera, el robot se desplazahasta esta localizacion.
Ademas, se ha introducido un sistema de teletransporte que permite al operadorescoger el punto de vista desde el que observar la escena y comandar el robot. Parateletransportarse, el usuario solo tiene que presionar un boton en el mando y dirigirla parabola hacia el punto deseado del suelo. Este sistema es especialmente util paratener una vision adecuada de las tareas de manipulacion y enviar las metas del efectorde forma precisa.
Elena Pena Tapia 49
4. DESARROLLO
50 ETSII UPM
Capıtulo 5
Experimentacion y Pruebas
Dentro de este apartado se detallan tanto el conjunto de experimentos realizadoscon la interfaz de monitorizacion como las pruebas de la interfaz de comandado.
5.1. Monitorizacion
Los experimentos de monitorizacion se llevaron a cabo con el fin de evaluar elimpacto no solo de la inmersion, sino tambien de la componente predictiva en misionesmulti-robot.
Se contabilizaron cuatro interfaces diferentes (que podrıan verse como 2 interfacescon 2 modos cada una): la interfaz de RV en modo predictivo, la interfaz de RV en modono predictivo, una interfaz convencional en modo predictivo y la misma en modo nopredictivo. Estas interfaces se emplearon en la monitorizacion de 8 misiones multi-robotdiferentes, descritas en el apartado 4.1.2.1.
Se seleccionaron un total de 24 sujetos de diferentes edades, generos y estudios. Entotal, participaron 9 mujeres y 15 hombres, de edades entre 21 y 34 anos y distintosniveles de estudios: Grado (16), Master (2), Doctorando (5) y Doctor (1), la figura 5.1muestra a un sujeto llevando a cabo una monitorizacion.
Cada sujeto utilizo 2 interfaces para monitorizar 2 misiones diferentes. Se realizouna distribucion de las misiones de modo que se neutralizara el efecto aprendizaje y nohubiera correlaciones entre interfaces y misiones, de manera que los resultados de lasinterfaces se vieran influidos por las misiones con las que se probaron.
El numero de muestras para el diseno de experimentos asciende a 24 para la com-paracion entre interfaces de RV e interfaces convencionales, y 12 en las comparacionesIC vs ICP vs IRV vs IRVP. En el primer caso, las 24 muestras permiten tomar con-
Elena Pena Tapia 51
5. EXPERIMENTACION Y PRUEBAS
clusiones con un nivel de confianza del 95 % y una potencia estadıstica del 30 %. Enel segudo caso, el numero de muestras no alcanza el mınimo necesario para obtenerconclusiones significativas, si bien es posible detectar tendencias y obtener informacionpara futuros desarrollos. Se asume que las variables medidas son independientes (dadaa la baja correlacion medida en el capıtulo anterior), y se establecen las hipotesis nulaspara cada variable de ICs = IRVs en el primer caso, e IC = ICP, IC = IRV, IRV =IRVP..... (todas las comparaciones dos a dos) en el segundo.
Figura 5.1: Sujeto llevando a cabo los experimentos
Las interfaces se evaluaron segun la carga de trabajo del operador y su concienciade la situacion. Para obtener valores para estas variables, se utilizaron los cuestionariosNASA-TLX y SAGAT.
El desarrollo de los experimentos se realizo de acuerdo a las siguientes pautas:
1. Explicacion de las misiones. Se proporcionaron los datos necesarios para lacomprension de lo que se iba a monitorizar, siguiendo este guion:
En este experimento deberas observar misiones multi-robot, recoger informa-cion y contestar una serie de preguntas acerca de lo que has visto.
El objetivo de las misiones es por un lado detectar y extinguir fuegos, y porotro, encontrar y seguir intrusos.
Los elementos de las misiones son 2 drones (uno rojo, uno azul), un robotterrestre, un fuego y un deposito con agua.
Los drones pueden ejecutar las siguientes tareas: Inicio (despegue), Vigilan-cia (recorrer area para detectar fuego/intruso), Reconocimiento (visitar lospuntos donde ha habido detecciones para comprobar el estado), Seguimiento
52 ETSII UPM
5.1 Monitorizacion
(persecucion de intruso), Carga (de agua del deposito), Descarga (de aguasobre el fuego), Fin (aterrizaje).
Es importante recordar donde estan los drones, que tareas estan ejecutando,el nivel de baterıa, etc.
2. Explicacion de las interfaces.
Interfaz Convencional (IC): Explicacion del mapa, los elementos (UAVs,fuego, UGV), como se selecciona el UAV para ver los datos relacionados(baterıa y tarea).
Interfaz Predictiva Convencional (IPC): Explicacion del mapa, los ele-mentos (UAVs, fuego, UGV), la aparicion de alertas y la seleccion automaticadel UAV para ver los datos relacionados (baterıa y tarea).
Interfaz de Realidad Virtual (IRV): Explicacion del entorno (escenario yplataforma de observacion), el mecanismo de teletransporte, los elementos dela mision (UAVs, fuego, UGV) y la informacion de dichos elementos (baterıay tarea).
Interfaz de Realidad Virtual Predictiva (IRVP): Explicacion del en-torno (escenario y plataforma de observacion), el mecanismo de teletrans-porte, los elementos de la mision (UAVs, fuego, UGV), los componentes pre-dictivos (foco, nubes de humo) y la informacion de dichos elementos (baterıay tarea).
3. Anotacion de datos basicos del usuario: Edad, Genero, Estudios.
4. Ponderacion NASA-TLX: Se pide al usuario ordenar 6 variables (exigenciamental, fısica y temporal, esfuerzo, rendimiento y frustracion) segun la influenciaque estiman que puedan tener en la carga de trabajo, como muestra la figura 5.2).
5. Prueba con la interfaz #1:
Inicio: Comienza la monitorizacion de la mision multi-robot.
Parada #1: Se avisa al usuario de la parada inminente, 10 segundos despuesse para la interfaz.
Primer bloque SAGAT: El usuario responde 10 preguntas acerca de la mision(detalladas mas adelante).
Se retoma la monitorizacion: Se continua la mision desde el momento de laprimera parada.
Elena Pena Tapia 53
5. EXPERIMENTACION Y PRUEBAS
Parada #2: Se avisa al usuario de la parada inminente, 10 segundos despuesse para la interfaz.
Segundo bloque SAGAT: El usuario responde 10 preguntas acerca de lamision (detalladas mas adelante).
6. Prueba con la interfaz #2: Se repite el procedimiento para la interfaz #1.
7. Evaluacion NASA-TLX: El usuario evalua las 6 variables ordenadas inicial-mente (exigencia mental, fısica y temporal, esfuerzo, rendimiento y frustracion)con una puntuacion del 0 al 20, como muestra la figura 5.2.
8. Observaciones: El usuario procede a anotar voluntariamente cualquier comen-tario acerca del experimento realizado.
Figura 5.2: NASA-TLX: Muestra del cuestionario utilizado
El desarrollo de los experimentos muestra que cada mision evaluada se paraba 2veces para responder a las preguntas del cuestionario SAGAT. De forma general, lasprimeras paradas se situaban en torno a los minutos 1/2 de mision, mientras que las
54 ETSII UPM
5.1 Monitorizacion
segundas se encontraban en los minutos 2/3. De las 10 preguntas formuladas en cadaparada, 5 de ellas eran fijas: donde estan los drones (dibujar en mapa), de donde vienen(dibujar en mapa), adonde van (dibujar en mapa), que tarea esta realizando cada uno(1 pregunta por dron). Las 5 restantes eran especıficas para la mision que se estabamonitorizando, en ellas se preguntaban datos como la distancia de un UAV al fuego,agua o UGV, niveles de baterıa de los UAVs, que UAV descubrio el fuego/UGV, etc.La figura 5.3 muestra un ejemplo de cuestionario.
Figura 5.3: SAGAT: Un modelo de cuestionario
Elena Pena Tapia 55
5. EXPERIMENTACION Y PRUEBAS
5.2. Comandado
Los experimentos de monitorizacion ayudaron a determinar los beneficios que apor-ta la realidad virtual en lo referente a conocimiento de la situacion. Las pruebas decomandado, por otra parte, se centraron en comprobar la efectividad del metodo decomandado en realidad virtual.
Para ello, se procedio al envıo de sucesivos objetivos al robot, primero transmitiendounicamente la posicion del efector final, y mas adelante enviando tanto posicion comoorientacion. En el apartado de desarrollo ya se ha detallado que se decidio enviar laposicion del efector final agarrando una esfera. La figura 5.4 muestra como el brazo pasapor tres posiciones sucesivas en la realidad virtual frente a la imagen del planificador detrayectorias. La figura 5.5 muestra la evolucion de una trayectoria del brazo en Unityfrente a la evolucion del brazo real (ambas se realizaban de forma simultanea). Cabedestacar que la imagen de Unity muestra el punto de vista del operador.
56 ETSII UPM
5.2 Comandado
Figura 5.4: Izquierda, posiciones sucesivas del brazo en Unity. Derecha, evolucion vista
en Rviz (ROS).
Elena Pena Tapia 57
5. EXPERIMENTACION Y PRUEBAS
Figura 5.5: (1) Posicion inicial, envıo de meta con esfera de comandado.(2) Posicion final,
se alcanza la esfera de comandado.
58 ETSII UPM
Capıtulo 6
Resultados
En este capıtulo se presenta un analisis de los resultados obtenidos de los expe-rimentos y pruebas del capıtulo anterior. Una vez mas, se separan los apartados demonitorizacion y comandado.
6.1. Monitorizacion
Una vez efectuados los 24 experimentos planificados, se procedio al analisis de losresultados. La tabla 6.1 resume las puntuaciones medias de la carga de trabajo y con-ciencia de situacion obtenidas para cada interfaz, a partir de las respuestas de loscuestionarios NASA-TLX y SAGAT respectivamente. Ademas, se muestran los comen-tarios referentes a cada interfaz (positivos y negativos). La terminologıa usada es IC= Interfaz Convencional, ICP = Interfaz Convencional Predictiva, IRV = Interfaz deRealidad Virtual, IRVP = Interfaz de Realidad Virtual Predictiva,
Interfaz Carga de Trabajo Conciencia de Situacion Comentarios
(NASA-TLX) (SAGAT) (+/-)
IC 853 14.91 0/7
ICP 915 14.33 0/7
IRV 638 16.25 5/5
IRVP 740 16.46 10/5
Cuadro 6.1: Resumen de resultados de los experimentos
Un analisis rapido de las puntuaciones medias muestra que las interfaces inmersivas
Elena Pena Tapia 59
6. RESULTADOS
muestran una menor carga de trabajo y mayor conciencia de situacion, por lo que sepodrıan considerar mas adecuadas que las no imersivas. Por otro lado, tambien se puedeobservar que los efectos de la prediccion dependen del tipo de interfaz (convencional /RV) y de la variable a considerar (carga de trabajo/ conciencia de situacion). En lassecciones 6.1.1, 6.1.2 y 6.1.3 se estudian en profundidad los resultados obtenidos juntocon su relevancia estadıstica.
6.1.1. Carga de trabajo
Segun los resultados de la tabla 6.1, es posible ordenar las interfaces en orden cre-ciente de carga de trabajo de la siguiente manera: IRV, IRVP, IC e ICP. Este ordenmuestra que las interfaces en realidad virtual tienden a reducir la carga de trabajodel operador, mientras que las componentes predictivas tienden a aumentarla. No obs-tante, sin un analisis mas detallado no es posible determinar si estas conclusiones sonestadısticamente significativas.
Para comprobar el nivel de significancia de cada resultado, se desglosa la carga detrabajo en sus 6 variables fundamentales (exigencia mental, fısica y temporal, esfuerzo,rendimiento y frustracion), y se separan las interfaces. En este analisis, se comparanpor un lado las 4 interfaces (IC vs ICP vs IRV vs IRVP), y por otro se realiza unacomparacion 2 a 2 ignorando la componente predictiva (IC + ICP vs IRV + IRVP).
La figura 6.1 muestra los diagramas de cajas y bigotes resultantes del estudio delas variables comparando las 4 interfaces de forma individual. El analisis de la varianza(ANOVA) del conjunto de los datos muestra que no existen diferencias significativasentre las cargas de trabajo (tomando la nota global, suma de las 6 variables fundamen-tales) (F = 2.26, p = 0.1061). Sin embargo, en el estudio separado de las 6 variables sıes posible encontrar diferencias significativas con α = 0.05 en rendimiento (F = 2.59,p = 0.065) y frustracion (F = 3.37, p = 0.0266).
La figura 6.2 muestra los mismos diagramas para las interfaces agrupadas en losbloques mencionados: convencional vs RV. En este caso, el analisis ANOVA muestraque sı existen diferencias significativas con α = 0.05 entre las cargas de trabajo de losdos grupos de interfaces (F = 5.58, p = 0.0225). Cuando se estudian las 6 variables porseparado, se encuentran diferencias significativas en el esfuerzo (F = 4.54, p = 0.0384),rendimiento (F = 7.56, p = 0.0085) y frustracion (F = 8.47, p = 0.0055).
Finalmente, un analisis ANOVA de todas las posibles parejas de interfaces muestralos resultados de la tabla 6.2. Considerando un α = 0.10, IRV es significativamentemejor que IC e ICP en terminos de carga de trabajo, mientras el resto de diferenciasno se consideran significativas.
60 ETSII UPM
6.1 Monitorizacion
Figura 6.1: Diagrama de cajas de las 4 interfaces por separado: IC, ICP, IRV, IRVP
Figura 6.2: Diagrama de cajas de las 4 interfaces en 2 grupos: Convencionales (IC+ICP),
Realidad Virtual (IRV+IRVP)
En resumen, la carga de trabajo es significativamente menor en interfaces de realidadvirtual que en interfaces convencionales, ya sean estas predictivas o no predictivas.Curiosamente, los efectos de la prediccion sobre la carga de trabajo son negativos. Esteresultado se debe probablemente a un entrenamiento incorrecto de los usuarios para lainterpretacion de la componente predictiva, cuyos efectos de todos modos no resultansignificativos.
6.1.2. Conciencia de la Situacion
En cuanto a la conciencia de situacion, la tabla 6.1 permite ordenar las interfacessegun conciencia de situacion decreciente de la siguiente forma: IRVP, IRV, IC e ICP.
Elena Pena Tapia 61
6. RESULTADOS
ICP IRV IRVP
IC IC < ICP IC > IRV IC > IRVP
(F = 0.24, p = 0.63) (F = 3.34, p = 0.08) (F = 0.88, p = 0.36)
ICP - ICP > IRV ICP > IRVP
(F = 5.74, p = 0.03) (F = 2.18, p = 0.15)
IRV - - IRV < IRVP
(F = 0.89, p = 0.36)
Cuadro 6.2: Comparacion de las 4 interfaces (diferencias significativas en negrita).
Esta ordenacion muestra que las interfaces de realidad virtual tienden a aumentar laconciencia de situacion de los operadores, mientras que los efectos de las componentespredictivas varıan segun la interfaz. Una vez mas, es necesario un analisis estadısticomas detallado.
La figura 6.3 muestra los diagramas de cajas y bigotes para la conciencia de situacionobtenida en las cuatro interfaces (IC, ICP, IRV, IRVP) por separado, y los dos gruposde interfaces (ICs e IRVs). El analisis de la varianza ANOVA con α = 0.05 para lascuatro interfaces estudiadas por separado no proporciona resultados significativos (F= 1.49, p = 0.2296). No obstante, este mismo analisis para los dos grupos de interfacessı que determina una diferencia de conciencia de situacion significativa (F = 4.37, p =0.042).
Finalmente, el analisis ANOVA de cada pareja de interfaces indica los resultados dela tabla 6.3. En este caso, las interfaces IRV e IRVP son significativamente mejores quela ICP con α = 0.10 en lo referente a conciencia de situacion. El resto de diferenciasno resultan significativas.
En resumen, es posible afirmar que la realidad virtual mejora la conciencia de lasituacion de forma significativa, dado que su puntuacion en el cuestionario SAGATes significativamente superior a la de las interfaces convencionales. En este caso, losefectos de la prediccion dependen de la interfaz. Con la realidad virtual la prediccionmejora la conciencia de la situacion y con la interfaz convencional la reduce. Esto sedebe probablemente a las diferentes maneras de implementar la componente predictivaque existen en ambas interfaces. La implementacion en realidad virtual puede resul-tar mas intuitiva que la convencional. No obstante, estos efectos son una vez mas nosignificativos.
62 ETSII UPM
6.1 Monitorizacion
Figura 6.3: Diagrama de cajas de las 4 interfaces por separado (izq.) y los dos bloques de
interfaces (der.).
6.1.3. Evaluacion de los usuarios
En ultimo lugar, se procedera al analisis de las observaciones y sugerencias de losusuarios. Se extrajo un conjunto de 39 resenas de las interfaces: 15 positivas y 24negativas. Los resultados, mostrados en la tabla 6.1, se describen a continuacion.
La interfaz convencional obtuvo 7 crıticas negativas, relacionadas fundamentalmentea la complejidad de la informacion mostrada (3) y la necesidad de seleccionar manual-mente el UAV para obtener la informacion relevante (2).
La interfaz convencional predictiva recibio tambien 7 crıticas negativas. En estecaso, se referıan a la cantidad de informacion a manejar (3) y la complejidad de algunasvariables (3).
La interfaz de realidad virtual recibio 5 comentarios positivos y 5 negativos. Lospositivos mencionaban la facil comprension de las misiones (3) y lo entretenido que re-sultaba su uso (2). Los negativos trataban problemas relacionados con la plataforma deobservacion (3), incluyendo una perspectiva incomoda y la experimentacion de mareos.
Finalmente, la interfaz de realidad virtual predictiva recibio 10 resenas positivas y 5negativas. En este caso, los comentarios positivos alababan la facilidad de comprension(3), comodidad de uso (3), utilidad del teletransporte (1) y de la componente predictiva(1). Por otro lado, los negativos apuntaban a la dificultad de comprension de algunasvariables (3) y los ya mencionados problemas con la plataforma de observacion (2).
Elena Pena Tapia 63
6. RESULTADOS
ICP IRV IRVP
IC IC > ICP IC < IRV IC < IRVP
(F = 0.17, p = 0.68) (F = 1.22, p = 0.28) (F = 1.28, p = 0.23)
ICP - ICP < IRV ICP < IRVP
(F = 2.99, p = 0.09) (F = 3.25, p = 0.08)
IRV - - IRV < IRVP
(F = 0.05, p = 0.82)
Cuadro 6.3: Resultados SAGAT (diferencias significativas en negrita).
6.2. Comandado
Los resultados de las pruebas de comandado muestran que la interfaz reproducecorrectamente la posicion del brazo real y envıa las metas de forma precisa. Ademas,se ha confirmado el aumento de la seguridad del operador, que no corre riesgo de sergolpeado por el brazo de forma accidental. No obstante, se observaron una serie deaspectos que se encuentran sujetos a posibles mejoras:
Cuando la esfera marca una posicion inaccesible para el brazo la interfaz no lonotifica
Los movimientos de la pinza no se encuentran implementado
Se proponen modos de aplicacion de dichas mejoras en el apartado de lıneas futuras.
64 ETSII UPM
Capıtulo 7
Conclusiones y trabajos futuros
Este trabajo ha proporcionado una serie de conclusiones interesantes acerca de lasnuevas interfaces de realidad virtual, que se abordan en la seccion 7.1. Gracias a losresultados obtenidos se han abierto varias lıneas de investigacion en el departamentoque se detallan en la seccion 7.2.
7.1. Conclusiones
Este proyecto partıa de dos objetivos principales: el desarrollo de una interfaz demonitorizacion para misiones multi-robot y una interfaz de control para un robot mani-pulador. Como se ha descrito a lo largo de la memoria, ambos objetivos se han cumplidoadecuadamente. A continuacion se puede ver una descripcion mas detallada de las metasalcanzadas durante el desarrollo del proyecto.
Diseno de escenarios para misiones roboticas en Unity: Se han disenado dos es-cenarios para la monitorizacion de misiones multi-robot y dos escenarios para elcomandado del brazo robotico.
Implementacion de modelos de robots en Unity: Se han disenado y/o importadolos modelos de los tres robots involucrados en el proyecto (Parrot AR.Drone 2.0.,KUKA Youbot y Kinova Jaco2).
Creacion de animaciones e interacciones en realidad virtual: Se ha logrado unmovimiento realista de todos los robots, junto con otros elementos del escenario(fuego, humo...)
Manejo de los robots y gestion de su informacion en el entorno ROS: Se ha
Elena Pena Tapia 65
7. CONCLUSIONES Y TRABAJOS FUTUROS
adquirido conocimiento acerca de los nodos, topicos y mensajes intercambiadospor los robots.
Exploracion y desarrollo de comunicaciones entre ROS y Unity: Se han imple-mentado dos nodos de comunicacion, uno de creacion propia y otro adaptado deun paquete de software libre.
Diseno de modos efectivos de visualizacion de la informacion: Se ha integradola informacion de la mision y los robots en las imagenes de realidad virtual enelementos como las pantallas, el foco de relevancia, el humo del riesgo, etc.
Desarrollo de modos de comandado para el brazo robotico manipulador: Se hadado con un modo de comandado efectivo y seguro a traves de una esfera querepresenta la meta del efector del brazo.
Diseno y realizacion de experimentos para evaluacion de las interfaces: Se hallevado a cabo un completo conjunto de experimentos que han demostrado quelas interfaces de realidad virtual mejoran la conciencia de la situacion de losoperadores, reduciendo al mismo tiempo la carga de trabajo.
En conjunto, se puede concluir que el uso de realidad virtual puede resultar bene-ficioso para un elevado numero de tareas roboticas de diferentes ındoles, y que abrenuna vıa de investigacion con un gran potencial de desarrollo. En el siguiente apartadose proponen algunas lıneas futuras de investigacion que surgen de forma directa de estetrabajo, aunque sin duda es posible encontrar muchas otras.
7.2. Lıneas futuras
Este trabajo, por su caracter vanguardista, abre la puerta a multiples lıneas deinvestigacion. Se podrıa decir que es un desembarco en un mundo inexplorado con ungran potencial de expansion.
En el terreno de las interfaces de monitorizacion para misiones multi-robot, resul-tarıa interesante el desarrollo e integracion de un mayor numero de comandos multi-modales y una integracion mas natural de la componenete predictiva. Adicionalmente,se podrıa anadir una componente de comandado que permitiera la intervencion deloperador en momentos clave de la mision.
En cuanto al comandado del brazo robotico, ya se han sentado las bases de trabajosfuturos que incluirıan:
66 ETSII UPM
7.3 Impacto ambiental, economico y social
Modelado automatico del entorno del robot, a partir de nubes de puntos generadascon camaras 3D (Kinect).
Refuerzo de la informacion visual del robot y su entorno con la manipulabilidad,el espacio de trabajo, la planificacion de trayectorias, etc.
Desarrollo de un metodo de comandado directo que permita modificar una a unalas orientaciones de las articulaciones del robot.
Montaje del brazo sobre un robot movil y desarrollo de un metodo de comandadoconjunto (figura 7.1)
Figura 7.1: Ejemplo de como quedarıa el brazo montado sobre el robot Summit
7.3. Impacto ambiental, economico y social
Todo proyecto conlleva una serie de impactos que deben ser evaluados, en concretoresulta interesante el estudio del impacto ambiental, el economico y el social.
Cuando se trata de proyectos con una elevada componente software, como es elcaso de este TFG, el impacto ambiental suele resultar poco evidente. No obstante,tras unos instantes de reflexion es posible apreciar consecuencias indirectas que no seencentran a primera vista. En concreto, una implementacion generalizada de interfacesde teleoperacion y monitorizacion a distancia llevarıa asociada una disminucion en lostraslados de los operadores, con el consecuente impacto positivo en el medio ambiente.
Elena Pena Tapia 67
7. CONCLUSIONES Y TRABAJOS FUTUROS
Con esta tecnologıa se facilita que un operador, desde un lugar seguro, pueda asistir enuna zona asolada por una catastrofe, reduciendo ası su huella de carbono.
En lo referente al impacto economico, el abaratamiento de las tecnologıas de realidadvirtual y el desarrollo de proyectos en la lınea de este TFG esta impulsando la creacionde empresas especializadas en teleoperacion con RV. Este sector cuenta con potencia-les inversores que se encuentran a la espera de una generalizacion de los metodos decomandado con realidad virtual.
Finalmente, el impacto social es posiblemente el mas controvertido. Por un lado se hademostrado que estas tecnologıas facilitan la labor del operador, la hacen mas comoda yreducen los riesgos a los que pueda estar expuesto. Sin embargo, existe una controversiasimilar a la que presenta la automatizacion creciente de las tareas industriales, debidaa la presunta reduccion de mano de obra que lleva asociada. Es posible encontraruna gran cantidad de argumentos que defienden y rebaten esta afirmacion, y que nocompensa exponer en este apartado. No obstante, en discusiones como esta, convienerecordar que todas las revoluciones tecnologicas llevan asociados cambios sociales tantopositivos como negativos.
68 ETSII UPM
Capıtulo 8
Planificacion y presupuesto
8.1. Presupuesto
Para la elaboracion del presupuesto del proyecto se ha realizado un desglose de loscostes asociados al mismo:
Costes directos: Costes imputables directamente al proyecto, se han divididoen los costes asociados a los siguientes recursos:
• Recursos humanos: se han considerado como recursos humanos el inge-niero junior a cargo del proyecto junto con el ingeniero senior en calidad deproject manager.
• Recursos informaticos: en este apartado se tiene en cuenta la amortiza-cion de liecencias de software informatico.
• Recursos materiales: dentro de los recursos materiales se pueden diferen-ciar los recursos amortizables y los recursos de un solo uso.
Costes indirectos: Costes no imputables directamente al proyecto: consumoenergetico, costes de administracion, etc.
8.1.1. Costes directos
La figura 8.1 muestra el valor total de los costes directos del proyecto. A continuacionse detallara como se ha llegado a cada cifra.
Elena Pena Tapia 69
8. PLANIFICACION Y PRESUPUESTO
Figura 8.1: Costes directos totales
8.1.1.1. Recursos humanos
Para calcular el coste de los recursos humanos se multiplicara el numero de horasempleadas por el coste efectivo de cada hora. Se ha establecido un coste efectivo por horade 19,9 euros para el ingeniero jr., de acuerdo con el coste medio del sector industrialen el primer trimestre de 2017, figura 8.2. Este coste incluye el sueldo neto, incentivosy seguridad social (35 %). Se ha considerado que las funciones del project manageraportan un valor diferencial, y por tanto su coste laboral lleva asociado un aumentodel 50 % respecto a la media del sector.
Figura 8.2: Evolucion del coste laboral por hora en el sector industrial, fuente:
http://www.ine.es/jaxiT3/Tabla.htm?t=11219.
Para el calculo de las horas empleados, se ha tomado como base la planificaciontemporal del diagrama de GANTT (ver seccion 8.2), en la que se definen 8 meses detrabajo. Este proyecto se ha realizado bajo las condiciones de una beca de colaboracion,que establecen una relacion de 3 horas de trabajo por dıa laboral durante 8 meses. Estodetermina un total de 8 meses * 20 dıas/mes * 3h/dıa = 480 horas de trabajo parael ingeniero junior, y una cuarta parte de las mismas para el project manager. Cabedestacar que un trabajo de fin de grado lleva asociados 12 creditos ECTS (25 horas porcredito), lo que implicarıa un total de 375 horas efectivas. Este trabajo supera dicha
70 ETSII UPM
8.1 Presupuesto
cantidad por la mencionada beca de colaboracion.Los costes totales por recursos humanos se presentan el la figura 8.3.
Figura 8.3: Coste de recursos humanos
8.1.1.2. Recursos materiales
Dentro de los recursos materiales se pueden separar los recursos amortizables y losconsumibles. Los recursos amortizables se detallan en la figura 8.4, y los consumiblesaparecen en la 8.5. Se ha establecido por regla general que el periodo de amortizacionde los equipos es de 5 anos, y se ha ajustado el porcentaje de amortizacion al nivel deuso de cada recurso (tiempo de uso y numero de usuarios).
Figura 8.4: Coste de recursos materiales amortizables
Figura 8.5: Coste de recursos materiales consumibles
Elena Pena Tapia 71
8. PLANIFICACION Y PRESUPUESTO
8.1.1.3. Recursos informaticos
En cuanto a los recursos informaticos, se ha establecido el coste de la licencia desoftware por programa y el coste de amortizacion de dicha licencia imputable al proyec-to, figura 8.6. Gran parte del software es libre o se ha obtenido con licencias gratuitas.La licencia de MATLAB corre a cargo de la UPM y es anual, por tanto se ha divididoentre el numero de alumnos de la UPM para obtener el porcentaje de amortizacion.
Figura 8.6: Coste de recursos informaticos
8.1.2. Costes indirectos
La figura 8.7 muestra la relacion de costes indirectos y su cuantıa para el periodode duracion del proyecto.
Figura 8.7: Costes indirectos totales
8.1.3. Coste total del proyecto
Sumando el total de los costes directos y de los indirectos se obtiene el coste totaldel proyecto, que asciende a 18.744,95 euros, como se puede ver en la figura 8.8. Se ha
72 ETSII UPM
8.2 Estructura de Descomposicion del Proyecto y Diagrama de GANTT
considerado que el proyecto lo realiza una empresa y lo ofrece a otra como proyectoexterno con los impuestos correspondientes.
Figura 8.8: Coste total del proyecto
8.2. Estructura de Descomposicion del Proyecto y Dia-
grama de GANTT
Para la EDP (Estructura de Descomposicion del Proyecto) se ha dividido el trabajoen bloques ordenados en tres niveles (figura 8.9). El primer nivel se ve resaltado enrojo, el segundo en verde, y el tercero se compone de los diferentes paquetes de trabajomarcados en amarillo, azul y violeta.
En lo referente a la ordenacion temporal, se ha empreado un diagrama de GANTTdisenado en Microsoft Project (figura 8.10) en el que se pueden observar las distintastareas y las relaciones de precesion existentes entre ellas. Para la construccion de dichodiagrama, se han tomado las siguientes consideraciones:
Fecha de inicio: 05/07/2016
Fecha de finalizacion: 23/06/2017
Parada de verano + inicio de curso: del 15/07/2016 al 03/10/2016
Parada de navidad + examenes: del 23/12/2016 al 01/02/2017
Duracion total del proyecto descartando paradas: 8 meses
Elena Pena Tapia 73
8. PLANIFICACION Y PRESUPUESTO
Figura 8.9: EDP
74 ETSII UPM
8.2 Estructura de Descomposicion del Proyecto y Diagrama de GANTT
Figura 8.10: Diagrama de GANTT del trabajo
Elena Pena Tapia 75
8. PLANIFICACION Y PRESUPUESTO
76 ETSII UPM
Bibliografıa
[1] R Codd-Downey, P Mojiri Forooshani, A Speers, H Wang, and M Jenkin.From ROS to unity: Leveraging robot and virtual environment middleware
for immersive teleoperation. In Information and Automation (ICIA), 2014 IEEEInternational Conference on, pages 932–936. IEEE, 2014. xvii, 15, 16, 24
[2] Ali Sekmen, Ahmet Bugra Koku, and Saleh Zein-Sabatto. Human robot inter-
action via cellular phones. In Systems, Man and Cybernetics, 2003. IEEE InternationalConference on, 4, pages 3937–3942. IEEE, 2003. 5
[3] Jessie YC Chen, Ellen C Haas, and Michael J Barnes. Human performan-
ce issues and user interface design for teleoperated robots. IEEE Transac-
tions on Systems, Man, and Cybernetics, Part C (Applications and Reviews),
37(6):1231–1245, 2007. 5, 6, 8, 9
[4] David D Woods, James Tittle, Magnus Feil, and Axel Roesler. Envisioning
human-robot coordination in future operations. IEEE Transactions on Sys-
tems, Man, and Cybernetics, Part C (Applications and Reviews), 34(2):210–
218, 2004. 6
[5] Jijun Wang, Michael Lewis, and Stephen Hughes. Gravity-referenced attitu-
de display for teleoperation of mobile robots. In Proceedings of the Human
Factors and Ergonomics Society Annual Meeting, 48, pages 2662–2666. SAGE
Publications Sage CA: Los Angeles, CA, 2004. 7
[6] Mary L Cummings, Sylvain Bruni, S Mercier, and PJ Mitchell. Automation
architecture for single operator, multiple UAV command and control. Technical
report, DTIC Document, 2007. 6
[7] Robert J Lysaght, Susan G Hill, AO Dick, Brian D Plamondon, and Paul M
Linton. Operator workload: Comprehensive review and evaluation of operator
workload methodologies. Technical report, DTIC Document, 1989. 7
[8] Neville Moray. Mental workload: Its theory and measurement, 8. Springer
Science & Business Media, 2013. 7
Elena Pena Tapia 77
BIBLIOGRAFIA
[9] Sandra G Hart and Lowell E Staveland. Development of NASA-TLX (Task
Load Index): Results of empirical and theoretical research. Advances in psy-
chology, 52:139–183, 1988. 7
[10] Mica R Endsley. Design and evaluation for situation awareness enhancement.
In Proceedings of the human factors and ergonomics society annual meeting,
32, pages 97–101. SAGE Publications, 1988. 7
[11] Marie-Luce Bourguet. Designing and Prototyping Multimodal Commands.
In INTERACT, 3, pages 717–720, 2003. 8
[12] Patrizia Grifoni. Multimodal human computer interaction and pervasive ser-
vices. IGI Global, 2009. 8
[13] Brian D Simpson, Robert S Bolia, and Mark H Draper. Spatial audio dis-
play concepts supporting situation awareness for operators of unmanned aerial
vehicles. Human Performance, Situation Awareness, and Automation: Cu-
rrent Research and Trends HPSAA II, Volumes I and II, 2:61, 2013. 8
[14] Stefano Scheggi, Marco Aggravi, Fabio Morbidi, and Domenico Prattichiz-
zo. Cooperative human-robot haptic navigation. In Robotics and Automation
(ICRA), 2014 IEEE International Conference on, pages 2693–2698. IEEE,
2014. 9
[15] Z Ma and P Ben-Tzvi. Design and Optimization of a Five-Finger Haptic Glove
Mechanism. J. Mechanisms Robotics, 7:4, 2015. 9
[16] Valiallah Mani Monajjemi, Shokoofeh Pourmehr, Seyed Abbas Sadat, Fei
Zhan, Jens Wawerla, Greg Mori, and Richard Vaughan. Integrating multi-
modal interfaces to command UAVs. In Proceedings of the 2014 ACM/IEEE
international conference on Human-robot interaction, pages 106–106. ACM,
2014. 9
[17] S Kavitha, S Veena, and R Kumaraswamy. Development of automatic speech
recognition system for voice activated Ground Control system. In Trends in
Automation, Communications and Computing Technology (I-TACT-15), 2015
International Conference on, 1, pages 1–5. IEEE, 2015. 9
[18] Tomas Mantecon del Valle, Blanco Adan, Fernando Jaureguizar Nunez,
Narciso Garcıa Santos, et al. New generation of human machine interfaces
for controlling UAV through depth based gesture recognition. 2014. 9
[19] Jawad Nagi, Alessandro Giusti, Gianni A Di Caro, and Luca M Gambardella.
Human control of UAVs using face pose estimates and hand gestures. In
Proceedings of the 2014 ACM/IEEE international conference on Human-robot
interaction, pages 252–253. ACM, 2014. 9
78 ETSII UPM
BIBLIOGRAFIA
[20] Daniel J Barber, Thomas M Howard, and Matthew R Walter. A multimodal
interface for real-time soldier-robot teaming. In SPIE Defense+ Security,
pages 98370M–98370M. International Society for Optics and Photonics, 2016.
10
[21] Andrzej Czyzewski, Piotr Dalka, B Kunka, P Odya, et al. Multimodal
human-computer interfaces based on advanced video and audio analysis. In
Human-Computer Systems Interaction: Backgrounds and Applications 3, pa-
ges 87–102. Springer, 2014. 10
[22] Leonardo Roza Melo, Aline Cristina Antoneli de Oliveira, Priscila Basto
Fagundes, Maria Jose Baldessar, and Luciana Schmitz. Usability Analysis of
Multimodal Interface Human-Computer Interaction Based on Artificial Voice.
Advanced Science Letters, 22(10):3146–3150, 2016. 10
[23] Changmok Oh, Jeong-Mook Lim, Heesook Shin, Minkyu Kim, and Hyun-Tae
Jeong. Development of multimodal surface interface for audio and tactile feed-
back. In Consumer Electronics (ICCE), 2015 IEEE International Conference
on, pages 592–593. IEEE, 2015. 10
[24] Sara A Lu, Christopher D Wickens, Julie C Prinet, Shaun D Hutchins, Na-
dine Sarter, and Angelia Sebok. Supporting interruption management and
multimodal interface design: Three meta-analyses of task performance as a
function of interrupting task modality. Human factors, 55(4):697–724, 2013.
10
[25] Juan Pablo Carrascal and Roel Vertegaal. Effects of Tactile Feedback on the
Perception of Virtual Shapes on Non-Planar DisplayObjects. In Proceedings
of the 2017 CHI Conference on Human Factors in Computing Systems, pages
4417–4423. ACM, 2017. 10
[26] Xiaolei Hou and Robert Mahony. An intuitive multimodal haptic interface
for teleoperation of aerial robots. In Robotics and Automation (ICRA), 2014
IEEE International Conference on, pages 838–845. IEEE, 2014. 10
[27] Carlos Diaz and Shahram Payandeh. Multimodal Sensing Interface for Haptic
Interaction. Journal of Sensors, 2017, 2017. 10
[28] Jonathan Cacace, Riccardo Caccavale, Alberto Finzi, and Vincenzo Lippie-
llo. Attentional multimodal interface for multidrone search in the Alps. In
Systems, Man, and Cybernetics (SMC), 2016 IEEE International Conference
on, pages 001178–001183. IEEE, 2016. 10
[29] Euan Freeman, Graham Wilson, Dong-Bach Vo, Alex Ng, Ioannis Politis,
and Stephen Brewster. Multimodal feedback in HCI: Haptics, non-speech
Elena Pena Tapia 79
BIBLIOGRAFIA
audio, and their applications. In The Handbook of Multimodal-Multisensor
Interfaces, pages 277–317. Association for Computing Machinery and Morgan
& Claypool, 2017. 10
[30] Emily Fujimoto and Matthew Turk. Non-visual navigation using combined
audio music and haptic cues. In Proceedings of the 16th International Confe-
rence on Multimodal Interaction, pages 411–418. ACM, 2014. 10
[31] Philip R Cohen and Sharon Oviatt. Multimodal speech and pen interfaces.
In The Handbook of Multimodal-Multisensor Interfaces, pages 403–447. Asso-
ciation for Computing Machinery and Morgan & Claypool, 2017. 10
[32] Michael McTear, Zoraida Callejas, and David Griol. Implementing Multi-
modal Conversational Interfaces Using Android Wear. In The Conversational
Interface, pages 359–376. Springer, 2016. 10
[33] Jacques Terken, Pierre Levy, Chao Wang, Juffrizal Karjanto, Nidzamud-
din Md Yusof, Felix Ros, and Sergej Zwaan. Gesture-based and haptic inter-
faces for connected and autonomous driving. In Advances in Human Factors
and System Interactions, pages 107–115. Springer, 2017. 10
[34] Eshed Ohn-Bar and Mohan Manubhai Trivedi. Hand gesture recognition
in real time for automotive interfaces: A multimodal vision-based approach
and evaluations. IEEE transactions on intelligent transportation systems,
15(6):2368–2377, 2014. 10
[35] Jesus Savage-Carmona, Mark Billinghurst, and Alistair Holden. The Vir-
Bot: a virtual reality robot driven with multimodal commands. Expert Systems
with Applications, 15(3):413–419, 1998. 10
[36] Nikolaos Kardaris, Isidoros Rodomagoulakis, Vassilis Pitsikalis, Antonis
Arvanitakis, and Petros Maragos. A Platform for Building New Human-
Computer Interface Systems that Support Online Automatic Recognition of
Audio-Gestural Commands. In Proceedings of the 2016 ACM on Multimedia
Conference, pages 1169–1173. ACM, 2016. 10
[37] Tetsushi Oka and Keisuke Matsushima. Multimodal manipulator control in-
terface using speech and multi-touch gesture recognition. In Proceedings of
the Tenth Annual ACM/IEEE International Conference on Human-Robot In-
teraction Extended Abstracts, pages 21–22. ACM, 2015. 10
[38] Jeffrey T Hansberger. Development of the Next Generation of Adaptive
Interfaces. Technical report, DTIC Document, 2015. 9
80 ETSII UPM
BIBLIOGRAFIA
[39] Felix Dıez Arias, Juan Jesus Roldan Gomez, and Antonio Barrientos Cruz.
Modelado y Analisis de Misiones Multi-Robot mediante Minerıa de Procesos.
In Actas de las XXXVII Jornadas de Automatica, 1, pages 513–520, Madrid,
Septiembre 2016. Comite Espanol de Automatica (CEA-IFAC). Robotica y
Cibernetica RobCib. 10
[40] Ming Hou, Haibin Zhu, MengChu Zhou, and G Robert Arrabito. Optimizing
operator–agent interaction in intelligent adaptive interface design: A concep-
tual framework. IEEE Transactions on Systems, Man, and Cybernetics, Part
C (Applications and Reviews), 41(2):161–178, 2011. 10
[41] David Sanz Munoz. Cognitive risk perception system for obstacle avoidance in
outdoor mUAV missions. PhD thesis, Industriales, 2015. 11
[42] J. J Roldan, Miguel A Olivares-Mendez, J del Cerro, and Barrientos. A.
Analyzing and Improving Multi-Robot Missions by using Process Mining. Au-
tonomous Robots, 2017 (Under review). 12, 33
[43] Juan Jesus Roldan, Pablo Garcia-Aunon, Jaime del Cerro, and Antonio Ba-
rrientos. Determining mission evolution through UAV telemetry by using
decision trees. In Systems, Man, and Cybernetics (SMC), 2016 IEEE Inter-
national Conference on, pages 000188–000193. IEEE, 2016. 12
[44] Hironao Yamada, Takayoshi Muto, and Goshin Ohashi. Development of a
telerobotics system for construction robot using virtual reality. In Control
Conference (ECC), 1999 European, pages 2975–2979. IEEE, 1999. 12
[45] Alexandre Monferrer and David Bonyuet. Cooperative robot teleoperation
through virtual reality interfaces. In Information Visualisation, 2002. Procee-
dings. Sixth International Conference on, pages 243–248. IEEE, 2002. 12
[46] Masmoudi Mostefa, L Kaddour El Boudadi, A Loukil, Khelf Mohamed, and
Dahane Amine. Design of mobile robot teleoperation system based on virtual
reality. In Control, Engineering & Information Technology (CEIT), 2015 3rd
International Conference on, pages 1–6. IEEE, 2015. 12
[47] Guoliang Zhong, Yukinori Kobayashi, Yohei Hoshino, and Takanori Emaru.
Intuitive teleoperation of nonholonomic mobile robot with a manipulator based
on virtual reality and WiFi. 2012. 12
[48] Emna Baklouti, Mohamed Jallouli, Lobna Amouri, and Nader Ben Amor.
Remote control of mobile robot through 3D virtual reality environment. In
Individual and Collective Behaviors in Robotics (ICBR), 2013 International
Conference on, pages 9–14. IEEE, 2013. 12
Elena Pena Tapia 81
BIBLIOGRAFIA
[49] Ding Cheng-jun, Duan Ping, Zhang Ming-lu, and Zhang Yan-fang. Design
of mobile robot teleoperation system based on virtual reality. In Automation
and Logistics, 2009. ICAL’09. IEEE International Conference on, pages 2024–
2029. IEEE, 2009. 12
[50] Tiehua Chen, Dingxuan Zhao, and Zhuxin Zhang. Research on the tele-
operation robot system with tele-presence based on the virtual reality. In
Robotics and Biomimetics, 2007. ROBIO 2007. IEEE International Confe-
rence on, pages 302–306. IEEE, 2007. 12
[51] Airs Lin, Aleksander Milshteyn, Garth Herman, Manuel Garcia, Charles
Liu, Khosrow Rad, Darrell Guillaume, and Helen Boussalis. Virtual reality
head-tracking observation system for mobile robot. In Embedded Computing
(MECO), 2014 3rd Mediterranean Conference on, pages 152–157. IEEE, 2014.
12
[52] Elias Matsas and George-Christopher Vosniakos. Design of a virtual reality
training system for human–robot collaboration in manufacturing tasks. In-
ternational Journal on Interactive Design and Manufacturing (IJIDeM),
11(2):139–153, 2017. 12
[53] JJ Ruiz, A Viguria, JR Martinez-de Dios, and A Ollero. Immersive displays
for building spatial knowledge in multi-UAV operations. In Unmanned Aircraft
Systems (ICUAS), 2015 International Conference on, pages 1043–1048. IEEE,
2015. 12
[54] E Freund and J Rossmann. Intuitive control of a multi-robot-system by means
of projective virtual reality. In Multisensor Fusion and Integration for Inte-
lligent Systems, 1996. IEEE/SICE/RSJ International Conference on, pages
273–280. IEEE, 1996. 12
[55] Jessie YC Chen, Michael J Barnes, and Michelle Harper-Sciarini. Supervi-
sory control of multiple robots: Human-performance issues and user-interface
design. IEEE Transactions on Systems, Man, and Cybernetics, Part C (Ap-
plications and Reviews), 41(4):435–454, 2011. 13
[56] Andre Gaschler, Maximilian Springer, Markus Rickert, and Alois Knoll.
Intuitive robot tasks with augmented reality and virtual obstacles. In Robo-
tics and Automation (ICRA), 2014 IEEE International Conference on, pages
6026–6031. IEEE, 2014. 13
[57] HC Fang, SK Ong, and AYC Nee. A novel augmented reality-based interface
for robot path planning. International Journal on Interactive Design and
Manufacturing (IJIDeM), 8(1):33–42, 2014. 13
82 ETSII UPM
BIBLIOGRAFIA
[58] Rong Wen, Wei-Liang Tay, Binh P Nguyen, Chin-Boon Chng, and Chee-Kong
Chui. Hand gesture guided robot-assisted surgery based on a direct augmented
reality interface. Computer methods and programs in biomedicine, 116(2):68–
80, 2014. 13
[59] Fabrizio Ghiringhelli, Jerome Guzzi, Gianni A Di Caro, Vincenzo Caglioti,
Luca M Gambardella, and Alessandro Giusti. Interactive augmented reality
for understanding and analyzing multi-robot systems. In Intelligent Robots and
Systems (IROS 2014), 2014 IEEE/RSJ International Conference on, pages
1195–1201. IEEE, 2014. 13
[60] Jill L Drury, Justin Richer, Nathan Rackliffe, and Michael A Goodrich.
Comparing situation awareness for two unmanned aerial vehicle human inter-
face approaches. Technical report, DTIC Document, 2006. 13
[61] Michael D Coovert, Tiffany Lee, Ivan Shindev, and Yu Sun. Spatial augmen-
ted reality as a method for a mobile robot to communicate intended movement.
Computers in Human Behavior, 34:241–248, 2014. 13
[62] Nico Li, Stephen Cartwright, Aditya Shekhar Nittala, Ehud Sharlin, and
Mario Costa Sousa. Flying Frustum: A Spatial Interface for Enhancing
Human-UAV Awareness. In Proceedings of the 3rd International Conferen-
ce on Human-Agent Interaction, pages 27–31. ACM, 2015. 13
[63] Krzysztof Foit. Mixed reality as a tool supporting programming of the robot.
In Advanced Materials Research, 1036, pages 737–742. Trans Tech Publ, 2014.
13
[64] Wolfgang Honig, Christina Milanes, Lisa Scaria, Thai Phan, Mark Bolas,
and Nora Ayanian. Mixed reality for robotics. In Intelligent Robots and
Systems (IROS), 2015 IEEE/RSJ International Conference on, pages 5382–
5387. IEEE, 2015. 14
[65] M Robinson, J Laurence, J Zacher, A Hogue, R Allison, LR Harris, M Jen-
kin, and W Stuerzlinger. Growing IVY: Building the Immersive Visual en-
vironment at York. In ICAT, Proc. 11th Int. Conf. on Artificial Reality and
Telexistance, 2002. 15
[66] Jeremie Allard, Valerie Gouranton, Loick Lecointre, Sebastien Limet, Em-
manuel Melin, Bruno Raffin, and Sophie Robert. FlowVR: a middleware for
large scale virtual reality applications. In Euro-par 2004 Parallel Processing,
pages 497–505. Springer, 2004. 15
[67] Ogre. Ogre3D. 15
Elena Pena Tapia 83
BIBLIOGRAFIA
[68] U.Technologies. Unity. 15
[69] J Ripton and L Prasuethsut. The VR race: What you need to know about
Oculus Rift, HTC Vive and more. Techradar, 2015. 16
[70] M Taboada, JJ Roldan, and A Barrientos. Interfaz Inteligente y Adaptativa
para Personas con Discapacidad. In XXXVII Jornadas de Automatica. Comite
Espanol de Automatica (CEA-IFAC), 2016. 17
[71] Ioan A. Sucan, Mark Moll, and Lydia E. Kavraki. The Open Motion Planning
Library. IEEE Robotics & Automation Magazine, 19(4):72–82, December 2012.
20
[72] J. J. Kuffner and S. M. LaValle. RRT-connect: An efficient approach to
single-query path planning. In Proceedings 2000 ICRA. Millennium Confe-
rence. IEEE International Conference on Robotics and Automation. Symposia
Proceedings (Cat. No.00CH37065), 2, pages 995–1001 vol.2, 2000. 20
[73] Diederick C Niehorster, Li Li, and Markus Lappe. The Accuracy and Pre-
cision of Position and Orientation Tracking in the HTC Vive Virtual Reality
System for Scientific Research. i-Perception, 8(3):2041669517708205, 2017. 23
[74] Min-Woo Seo, Song-Woo Choi, Sang-Lyn Lee, Eui-Yeol Oh, Jong-Sang Baek,
and Suk-Ju Kang. Photosensor-Based Latency Measurement System for Head-
Mounted Displays. Sensors, 17(5):1112, 2017. 23
[75] Morgan Quigley, Ken Conley, Brian Gerkey, Josh Faust, Tully Foote, Je-
remy Leibs, Rob Wheeler, and Andrew Y Ng. ROS: an open-source Robot
Operating System. In ICRA workshop on open source software, 3, page 5.
Kobe, 2009. 24, 35
[76] Christopher Crick, Graylin Jay, Sarah Osentoski, Benjamin Pitzer, and
Odest Chadwicke Jenkins. Rosbridge: Ros for non-ros users. In Proceedings
of the 15th International Symposium on Robotics Research, 2011. 29
[77] Oren Ben-Kiki, Clark Evans, and Brian Ingerson. YAML Ain’t Markup
Language (YAMLTM) Version 1.1. yaml. org, Tech. Rep, 2005. 29
[78] Douglas Crockford. The application/json media type for javascript object
notation (json). 2006. 29
[79] Tomas Krajnık, Vojtech Vonasek, Daniel Fiser, and Jan Faigl. AR-drone as
a platform for robotic research and education. In International Conference on
Research and Education in Robotics, pages 172–186. Springer, 2011. 34
84 ETSII UPM
BIBLIOGRAFIA
[80] Rainer Bischoff, Ulrich Huggenberger, and Erwin Prassler. Kuka youbot-a
mobile manipulator for research and education. In Robotics and Automation
(ICRA), 2011 IEEE International Conference on, pages 1–4. IEEE, 2011. 34
[81] Jan Dentler, Somasundar Kannan, Miguel Angel Olivares Mendez, and Hol-
ger Voos. A real-time model predictive position control with collision avoidan-
ce for commercial low-cost quadrotors. In Control Applications (CCA), 2016
IEEE Conference on, pages 519–525. IEEE, 2016. 34
Elena Pena Tapia 85
