interfaces para aplicaciones de · interfaces para aplicaciones de mero. ... virtual basada en la...

Septiembre

2008

Departamento de Ingeniería de Sistemas y Automática Programa de Doctorado en Ingeniería Mecatrónica

Interfaces para Aplicaciones de Telerrobóticas y de Teleoperación COSME RAFAEL MARCANO GAMERO.

Trabajo Tutelado de Investigación del Segundo Año del Programa de Doctorado en Ingeniería Mecatrónica.

Tutor: Prof. Dr. Jesús Manuel Gómez de Gabriel.

INTERFACES PARA APLICACIONES TELERROBÓTICAS Y DE TELEOPERACIÓN

A Denisis Margelys,

mi inspiración y motivo.

A mis hijos, en especial, a

Anaís Patricia y Rafael Antonio,

mis mejores amigos.

Pág.

º 1. 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 2. 2.1. 2.2. 2.2.1. 2.3. 2.3.1. 2.3.1.1. 2.4. 2.4.1. 2.5.

INDICE GENERAL LISTA DE FIGURAS CAPÍTULO 1 INTRODUCCIÓN Generalidades Objetivos Desde adentro de la Realidad Virtual Desde afuera de la Realidad Virtual Organización del trabajo Contextualización y Reconocimiento. CAPÍTULO 2. AREAS DE APLICACIONE DE SISTEMAS TELERROBÓTICOS Y DE TELEOPERACIÓN. Introducción Aplicaciones Inmersivas de Realidad Virtual.. Aplicación de la plataforma CAVE. Aplicaciones Médicas. Visualización y Análisis de Imágenes Digitales Tomografía Óptica Coherente Aplicaciones de Teleoperación de robots. Robot móvil explorador para inspección geológica. Conclusiones del capítulo

i iii

1 1 1 2 3 3 5 7 7 8 9

10 11 12 13 13 15

3. 3.1. 3.2. 3.3. 3.4. 3.4.1. 3.4.1.1. 3.4.1.1.1. 3.4.1.1.2. 3.4.1.2. 3.4.1.3. 3.4.2. 3.4.2.1. 3.4.2.2. 3.4.2.3. 3.5.

CAPÍTULO 3. MODELADO Y SIMULACIÓN EN ENTORNOS VIRTUALES. Introducción Lenguaje de Programación VRML. Lenguaje de Programación X3D. Consideraciones para la Implementación de una Interfaz Usuario/Robot en un Entorno Virtual. Cinemática Directa e Inversa. Jacobianos. Cinemática Directa usando Jacobianos. Cinemática Inversa usando Jacobianos. Descripción del Robot en términos de los parámetros de Denavit-Hartenberg. Análisis comparativo de los métodos de cálculo cinemático. Consideraciones sobre la implementación de un Robot en una Escena Virtual basada en la web. Componente de cálculo cinemático. Componente de interfaz de usuario. Modelado y animación de humanoides. Conclusiones del capítulo

17 17 19 20

21 21 22 23 24 27

29

32 33 33 34 38

4. 4.1. 4.2. 4.2.1.

CAPÍTULO 4. DISPOSITIVOS HÁPTICOS. Introducción Algunas Áreas de Aplicación e investigación. Edición de Música.

41 41 42 42

ii

4.2.2. 4.2.3. 4.2.4. 4.3. 4.4. 4.5.

Caracterización de patrones de perfusión de la sangre en la punta de un dedo. Exploración Háptica para determinar la Orientación de una Superficie de acuerdo a su Textura. Determinación de la dirección de una Fuerza, usando Dispositivos Hápticos. Uso de la Geometría de Riemann para medición de da Percepción Háptica. Consideraciones De Software Relacionado Con Dispositivos Hápticos. Conclusiones.

42

44

44

47 51 51

5. 5.1. 5.2. 5.2.1. 5.2.2. 5.2.3. 5.2.4. 5.2.4.1. 5.2.4.2. 5.3. 5.3.1. 5.3.2. 5.3.3. 5.3.3.1. 5.3.3.1.1. 5.3.3.1.2. 5.3.3.2. 5.3.3.3. 5.3.4. 5.3.4.1. 5.3.4.2. 5.3.4.3. 5.3.4.4. 5.3.4.4.1. 5.3.4.4.2. 5.3.4.4.3. 5.3.4.4.4. 5.3.4.4.5. 5.3.4.4.6. 5.3.4.4.7. 5.3.4.4.8. 5.3.4.5. 5.3.4.5.1. 5.3.4.5.2. 5.3.4.5.3. 5.3.4.5.4. 5.3.4.5.5. 5.3.4.5.6. 5.4.

DESCRIPCIÓN DE LOS LENGUAJES DE PROGRAMACIÓN Introducción Descripción de VRML Primitivas El nodo Shape Materiales Sensores de Tiempo e Interpoladores. Sensor de Tiempo Interpoladores Descripción de X3D. Plataforma de operación de X3D ¿Cómo hacer que Xj3D acepte código Java? Descripción de la herramienta X3D. Nodos (nodes) Tipos de acceso a los Campos. Reglas para la asignación de nombres a los campos. Campos (Fields) Eventos. Relaciones: Transformation hierachy Conceptos y Componentes de X3D. Conceptos Importantes. Estructura Abstracta de X3D. Algunos Comentarios sobre la Sintáxis de XML. Primitivas Geométricas de X3D. Nodo NavigationInfo Nodo ViewPoint Iluminación. Anchor Temporizadores (Timers) Interpoladores Enrutamiento de Eventos. ROUTER Animación de la traslación de un nodo transform Otros Sensores: Visibilidad, Proximidad y de Audio. Sensor de proximidad (ProximitySensor) Animación de un paralelepípedo en base a la cercanía del avatar Posicionamiento de un objeto en base a la posición del avatar. Sensor de Visibilidad (VisibilitySensor) El Nodo de Sonido (Sound). AudioClip Otros Lenguajes De Realidad Virtual.

53 53 53 54 54 56 57 58 61 62 63 63 67 69 69 70 70 71 71 71 72 74 79 80 81 82 83 84 84 85 86 86 87 88 89 90 91 92

5.5. 5.6.

Ejemplos de Aplicación Conclusiones del Capítulo. CAPÍTULO 6. CONCLUSIONES. REFERENCIAS

93 93 94

97 101

LISTA DE FIGURAS. Capítulo 2. Figura 2.1. Mundo virtual multiusuario Figura 2.2. Visualización en ambiente RV inmersivo Figura 2.3. Visualización 3D del cerebro humano, [5]. Figura 2.4. Visualización científica Figura 2.5. OCT del ojo humano. Figura 2.6. Vehículo teleoperado de exploración denominado Marsokhod. Capítulo 3. Figura 3.1. Ejes Figura 3.2. Modelo de un robot móvil de tres ruedas. Figura 3.3. Matrices jacobianas del robot móvil de tres ruedas. Figura 3.4. Jacobiano Inverso del robot móvil de tres ruedas. Figura 3.5. Regla de la mano derecha (rmf). Figura 3.6. Ubicación de los .3,2,1, ii Figura 3.7. Ubicación de los .3,2,1, iai Figura 3.8. Ubicación de los .3,2,1, ii Figura 3.9. Ubicación de los .3,2,1, idi Figura 3.10. Cálculo de la matriz de Transformación, T. Figura 3.11. Definición del prototipo en VRML/X3D Figura 3.12. Flujo de Datos entre componentes. Figura 3.13. Estructura de un Segmento del Robot en VRML/X3D Figura 3.14. Definición del prototipo rob_geo Figura 3.15. Definición del prototipo rob_kin Figura 3.16. Definición del prototipo rob_kin. Figura 3.17. Metacarpianos (mano izquierda) Figura 3.18. Puntos característicos sobre el cuerpo humano, [24]. Figura 3.19. Representación típica de humanoides, en términos del proyecto Capítulo 4. Figura 4.1. Variables de interés de la mano humana. (Tomado de [27]) Figura 4.2. Disposición de los sujetos sometidos a estudio, a) para reconocimiento de

longitudes de rectángulos, b) para estimación de amplitud de los ángulos de un triángulo.

Figura 4.3. Elipse de excentricidad yx ll / .

Figura 4.4. Histograma y función de distribución gaussiana de probabilidades ajustada para los resultados de un sólo individuo.

Capítulo 5. Figura 5.1. Ejes. Figura 5.2. Definición de un nodo Box. Figura 5.3. Definición de un nodo Sphere.

iv

Figura 5.4. Definición de un nodo Cone. Figura 5.5. Definición de un nodo Cylinider. Figura 5.7. Modificación del color de un objeto. Figura 5.8. TimeSensor en VRML Figura 5.9. Definición de TimeSensor en VRML. Figura 5.10. Definición de un Interpolador de color. Figura 5.11. Definición de un Interpolador de Color. Figura 5.12. Cambiando el color. Figura 5.13. Declaración de un SetField como público Figura 5.14. Arquitectura de X3D. Figura 5.15. Relación de X3D con XML. Figura 5.16. Estructura interna de un Scene Graph. Figura 5.17. Sistemas de Coordenadas. Figura 5.18. Conexiones entre nodos. Behaviour Graph . Figura 5.19. Ejemplo de routing de eventos. Figura 5.20. Tipos de datos definidos en X3D: Figura 5.21. Estructura de un nodo. Figura 5.22. Perfil. Figura 5.23. Estructura de un fichero X3D. Figura 5.24. Estructura de un fichero X3D/XML. Figura 5.25. Nodo Transform (1). Figura 5.26. Nodo Transform (2). Figura 5.27. Nodo Transform (3) Figura 5.28. Ejemplo Figura 5.29. Nodo Shape Figura 5.30. Nodo Appearance Figura 5.31. Nodo Material (1) Figura 5.32. Nodo Material (2) Figura 5.33. Primitivas Geométricas (1). Figura 5.34. Primitivas Geométricas (2). Figura 5.35. Ejemplo de definición de NavigationInfo Figura 5.36. Ejemplo de definición de ViewPoint Figura 5.37. Nodo ViewPoint (3). Figura 5.38. Varios ejemplos de ViewPoints Figura 5.39. Iluminación (1) Figura 5.40. Iluminación (2) Figura 5.41. Definición de un Anchor. Figura 5.42. Definición de un TimeSensor. Figura 5.43. Interpoladores. Figura 5.44. Interpoladores. Figura 5.45. Animación de Transform. Figura 5.46. Creación de tres objetos. Figura 5.47. Creación de un TimeSensor. Figura 5.48. Creación de tres interpoladores. Figura 5.49. Ejemplo de enrutamiento de los eventos. Figura 5.50. Creación de un ProximitySensor. Figura 5.51. Ubicación de los .3,2,1, idi Figura 5.52. Cálculo de la matriz de Transformación, T. Figura 5.53. Definición del prototipo en VRML/X3D Figura 5.54. Flujo de Datos entre componentes. Figura 5.55. Puntos de interés para definir un nodo de audio. Figura 5.56. Definición de un AudioClip. Figura 5.57. Robot basado en la web, desarrollado en VRML/EAI

Septiembre 2008 Cosme Rafael Marcano Gamero 1

1. INTRODUCCIÓN.

1.1. GENERALIDADES Telerrobótica y Teleoperación son las áreas de la robótica que se interesan en el control y operación de robots a distancia [1]. Su importancia en el mundo actual es indiscutible, en virtud del desarrollo de infinidad de aplicaciones de interés común que se han llevado a cabo en el transcurso de los últimos años. Estas aplicaciones, que van desde la operación de electrodomésticos con un simple mando a distancia, comúnmente referido como control remoto, hasta la guía a distancia de vehículos no tripulados dirigidos a la exploración submarina o en el espacio hostil de planetas lejanos, dan cuenta de la multiplicidad de áreas de aplicación de tales herramientas. La área de investigación médica no escapa a la utilización de la Telerrobótica y la Teleoperación como medios idóneos para prestar ayuda a distancia en casos de calamidades o incluso la simple prestación de servicios médicos a poblaciones que habiten en áreas lejanas en donde no se pueda disponer en forma continua de médicos y personal especializados. Estas áreas de aplicación de la Telerrobótica y Teleoperación serán tema del Capítulo 2.

Dentro del estudio de estas áreas de aplicación puede surgir la necesidad de desarrollar entornos de Realidad Virtual (RV), entendida ésta como una simulación en computadora de un sistema real o imaginario que posibilita a un usuario a ejecutar operaciones sobre el sistema simulado y mostrar los efectos en tiempo real [1]. La utilización de estos entornos en las aplicaciones de Telerrobótica y Teleoperación presenta muchísimas ventajas, que van desde la posibilidad de repetir las experiencias tantas veces como sea necesario hasta las consideraciones de seguridad que entraña el trabajar en condiciones controladas, en lugar de que los investigadores estén expuestos a ambientes hostiles y peligrosos. 1.2. OBJETIVOS. se propuso realizar una estudio de carácter documental, que cubriera diferentes tópicos afines a las mismas, como la implementación de escenas en entornos de Realidad Virtual, el desarrollo de aplicaciones de software que permitan interacción con los objetos dentro de dichas escenas virtuales, interfaces entre robots físicos con objetos dentro de las escenas, consideraciones matemáticas a

2 Cosme Rafael Marcano Gamero Septiembre 2008

tomar en cuenta a tiempo de diseñar e implementar robots dentro de tales escenas, lenguajes programación adecuados, etc. De esta manera, se pueden enunciar como objetivos de este trabajo, los siguientes:

a. Estudiar posibles aplicaciones de los sistemas telerrobóticos y de teleoperación.

b. Análisis de distintas alternativas que existen para la implementación de simulaciones de robots en entornos de Realidad Virtual.

c. Investigar y estudiar formas de interacción entre usuarios y los robots en el entorno virtual.

d. Documentar cuidadosamente los estudios.

La información recabada en este trabajo puede servir de plataforma teórico-práctica para abordar el desarrollo de una investigación sobre un tema más específico, relacionado con la Telerrobótica y la Teleoperaci

1.3. DESDE ADENTRO DE LA REALIDAD VIRTUAL

En vista de que la Realidad Virtual es una simulación en computadora, que implica el manejo de imágenes en 2D y 3D, requiere de lenguajes de programación apropiados. Es así como, desde la década de los 90‘s, se ha venido desarrollando el así llamado VRML (acrónimo de Virtual Reality Modeling Language), cuya versión VRML97 llegó a establecerse como el estándar ISO/IEC-14772-1, [12].

Cabe mencionar aquí la importancia que ie ha dado al estudio de la

modelación y simulación de entornos virtuales y sus relaciones con la Telerrobótica y la Teleoperación la Asociación Internacional para la Estandarización, mejor conocida por sus siglas en inglés ISO (International Organization for Standardization) así como la Comisión Internacional Electrotécnica, o IEC (International Electro-technical Commission), Ambas organizaciones se han esmerado en la elaboración de especificaciones minuciosamente documentadas que son de uso obligado de investigadores de la área.

Posteriormente, y utilizando al VRML97 como plataforma base, fue

desarrollado X3D (acrónimo de eXtensible 3D), reconocido bajo el estándar ISO/IEC-19775-1, apenas en el mes de Julio del 2007, y es, hoy por hoy, el estándar de la industria para el desarrollo de escenarios de Realidad Virtual, permitiendo la interacción con objetos y robots dentro de las escenas a través de la interfaz SAI (acrónimo de Scene Access Interface). La interfaz SAI es mucho más poderosa y completa que su predecesora EAI (External Authoring Interface), la cual ha caído en desuso.


Los entornos de Realidad Virtual pueden ser enteramente imaginarios y existir sólo en un mundo virtual conformado únicamente por imágenes bi- y tridimesionales. Pero también pueden consistir de escenas virtuales montadas sobre espacios físicos que contengan objetos reales, los cuales deban ser considerados por los usuarios y/o robots que interactúen dentro de esos entornos de RV.

En el natural interés de dar a ciertos robots apariencia humana, se han

realizado importantes esfuerzos para describir las medidas y proporciones corporales promedio de las personas, de acuerdo a su raza. 1.4. DESDE AFUERA DE LA REALIDAD VIRTUAL.

Para interactuar ya sea con avatares dentro de escenas enteranebte vituales,

es decir, que sólo existen en la memoria de un ordenador, o bien con robots físicos, teleoperados a través de Internet, existen una cantidad de soluciones diseñadas de acuerdo a cada aplicación. Así, en el primer caso, la interacción se da a través de software especiales, como los ya mencionados External Authoring Interface, EAI, [12] o su sucesor, el Scene Access Interface, o SAI [16]. En ambos casos, la interacción se sucede a través de comandos, que son introducidos por el usuario de la aplicación, por medio de teclados, ratones, joysticks, dispositivos del tipo exoesqueletos, etc. Esos comandos van a ser almacenados en bases de datos compartidas en tiempo real por los usuarios de la aplicación y son pasados a ésta en forma sincronizada, preservando el orden de llagada y la prioridad de cada comando. Naturalmente, los retardos de tiempo introducidos por la propia aplicación, el número de transacciones, la cantidad de usuarios en línea, la velocidad de conexión a Internet, entre otros factores, determinarán la velocidad con que sean ejecutados dich[os comandos y la ―naturalidad‖ con que se muevan los avatares en la escena [16][17].

El estudio, diseño e implementación de las interfaces entre los usuarios y los

entornos de Realidad Virtual es una sub-área no menos interesante y exigente de este tipo de aplicaciones. Estas interfaces son de naturaleza muy variada, y contemplan desde la simple entrada de datos a través de teclados o dispositivos punteros, como los conocidos ―ratones‖ y joysticks, hasta muy sofisticados ingenios que permiten varios niveles de realimentación, como visión y tacto.

1.5. ORGANIZACIÓN DEL TEXTO.

Como ya se ha esbozado, este trabajo consta de seis capítulos interrelacionados. En Capítulo 1 introducimos los temas a tratar y su interrelación. En el Capítulo 2 se explicaran algunas áreas de aplicación de la Telerrobótica y de la Teleoperación. Destacan en este capítulo algunos ejemplos de aplicación a la Medicina y a la exploración geológica a través de telecoamdo de robots móviles.


En el Capítulo 3 se habla, primeramente, de importantes consideraciones a tomar en cuenta a tiempo de modelado de un robot desde el punto de visa matemático. Dentro de este contexto, se comparan dos grandes métodos de descripción matemática de robots móviles como lo son las así llamadas matrices jacobianas, por un lado, y el método de Denavit-Hartenberg, por el otro, los cuales son utilizados para describir la cinemática directa e inversa de robots móviles.

En segundo lugar, se habla aquí de los las plataformas de programación e

interfaz de usuarios con escenarios virtuales basados en la web. En particularr, se introducen las dos plataformas que han venido a ser estándares de la insdustria, estas son: VRML97/EAI y X3D/SAI, vistas como representantes de un más amplio espectro de herramientas para estos fines, poniendo especial énfasis en la última, ya que es la de más reciente data.Detalles más específicos de estos lenguajes son tratados con más detenimiento en el Capítulo 5, en donde se hace, además, cierta comparación entre ellos.

La última parte del Capítulo 3 está dedicado al tratamiento del cuerpo humano

dentro del contexto de la RV, por lo que se trata de explicar cómo éste y sus partes pueden ser modelados en el mundo virtual. Se incluye la descripción de humanoides H-Amin, perteneciente a las especificaciones ISO/IEC19774 del X3D, las cuales están basadas en los resultados del proyecto CAESAR (Civilian American and European Surface Anthropometry Resource, Recurso Antropométrico de la Superficie de Civiles Europeos y Americanos).

El Capítulo 4 se ocupa del diseño y desarrollo de dispositivos hápticos. Se

revisan aquí los trabajos de algunos renombrados investigadores que han hecho ciertos aportes en temas como la discriminación de sentido y magnitud de fuerzas que actúan sobre dedos de la mano humana, con miras a reproducir el funcionamiento de esta maravillosa herramienta natural. Se revisan igualmente algunas técnicas propuestas para la cuantificación de la percepción en seres humanos; asimismo, se mencionan varios factores que afectan la percepción humana.

Las ideas generales de diseño e implementación de los dispositivos hápticos

(haptics) son revisadas en este capítulo. Para complementar la información relativa a los lenguajes de programación

orientados a la construcción de escenarios de RV, el Capítulo 5 describe en detalle las primitivas y la sintaxis de VRML y X3D. Además, se incluye cierta comparación con otros lenguajes orientados al mismo fin.

Por último, el Capítulo 6 recoge algunas consideraciones y conclusiones sobre

el contenido del trabajo.


1.6. CONTEXTUALIZACIÓN Y RECONOCIMIENTO.

Esta investigación ha sido realizada como requisito para satisfacer las

exigencias del Trabajo Tutelado de Segundo Año dentro del contexto del Programa de Doctorado en Ingeniería Mecatrónica, que se imparte en el Departamento de Ingeniería de Sistemas y Automática de la ilustre Universidad de Málaga, bajo la tutoría del Dr. Jesús Manuel Gómez de Gabriel, profesor titular de esta Casa de Estudios, y bajo la Coordinación General del Prof. Dr. Alfonso García Cerezo.

Se agradece la colaboración de Denisis Margelys Alonzo Rojas en la

transcripción y preparación de este trabajo.


Página intencionalmente dejada en blanco


2. AREAS DE APLICACIÖN DE SISTEMAS TELERROBÓTICOS Y DE TELEOPERACIÓN.

2.1. INTRODUCCIÓN

La Telerrobótica comprende todo lo concerniente al control a distancia de robots móviles, ya sean éstos reales o virtuales, es decir, ya sea un robot móvil encargado de la inspección de sitios geológicos de interés, o bien sea un humanoide creado dentro de una escena virtual. Muy de cerca a la Telerrobótica se encuentra la Teleoperación, la cual cubre el no menos interesante área de operación a distancia. Al igual que la Telerrobótica, la Teleoperación puede estar orientada a la operación a distancia de brazo robótico para la manipulación de sustancias peligrosas, o también puede estar orientada a la operación y manipulación de objetos dentro de un entorno virtual, construido en la memoria de una computadora.

El control de robots a distancia implica el diseño y desarrollo de

estrategias orientadas no sólo a la mera manipulación de objetos o a la operación de un brazo robótico diseñado para operar dentro de un espacio de trabajo bien delimitado y con capacidades específicas. El control a distancia debe considerar los modos de navegación del robot, la autonomía de éste, la forma de que disponga para adquirir datos del entorno que le permitan posicionarse apropiadamente y tomar decisiones para obtener la mejor manera de alcanzar un objetivo específico, la distancia a la cual está ubicado, los retardos de tiempo de transmisión y recepción de los comandos que dicha distancia pudiera introducir, las fuentes de ruido en el espacio de trabajo, así como la capacidad que tenga para reconocer y adaptarse a cambios que puedan presentarse en el entorno original para el cual fue programado, entre otras consideraciones.

Por otra parte, además del control de navegación del robot, se debe

tomar en cuenta la función para la cual fue diseñado. Surge allí la necesidad de diseñar mecanismos de operación de los brazos y piezas especiales que pueda poseer el robot. La operación a distancia de los propios brazos del robot así como de las herramientas de que disponga, constituye toda una gama de consideraciones especiales, como la selección de una herramienta específica, la fuerza que el robot debe aplicar sobre esa herramienta (lo cual dependerá también de la naturaleza del objeto a ser manipulado).


Los mecanismos de interacción con los robots, sean móviles o fijos, son de muy diversa naturaleza y, obviamente, los mecanismos diseñados para controlar u operar robots y objetos en un entorno físico no pueden ser utilizados, en general, para el control y operación en un entorno virtual.

En este capítulo, se presenta una revisión somera de las múltiples y muy

diversas áreas de aplicación de la Telerrobótica y la Teleoperación.

2.2. APLICACIONES INMERSIVAS DE REALIDAD VIRTUAL.

Las aplicaciones de Realidad Virtual hoy en día requieren de un alto nivel de inmersión, es decir, de la interacción directa entre usuarios y objetos, virtuales o no, ubicados dentro de una escena determinada. Esto se puede lograr utilizando una plataforma tipo CAVE, siglas en inglés de Cave Automatic Virtual Environment, o ambiente virtual automático tipo cueva, lo que significa que la escena virtual que se quiere crear o simular ocurre en un espacio tridimensional idealizado, que está limitado por seis lados, y que asemejan una cueva. Este tipo de ambientes requiere de poderosas estaciones de trabajo para gráficos 3D, con múltiples pantallas panorámicas que permitan desplegar y proyectar sobre la pared, dispositivos de estereovisión y de interacción, tales como seguidores (trackers) y fuentes luminosas, sensores de movimiento colocados incluso sobre las diferentes partes del cuerpo de los usuarios que interactúan en la escena, guantes y exoesqueletos con capacidades hápticas, etcétera.

Los ejemplos tradicionales de entornos virtuales están directamente

relacionados con el entretenimiento. Los videojuegos han sido utilizados por los diseñadores como plataforma propicia para el diseño y desarrollo de mecanismos de interacción cada vez más realista entre los usuarios y los objetos u otros usuarios dentro del mismo entorno. Se habla así de mundos virtuales multiusuarios, conformados por un escenario, contentivo de una serie de objetos, obstáculos y avatares que el usuario debe poder controlar a través de teclados, ratones, trackers, guantes hápticos, etc. La apariencia típica de un mundo virtual multiusuario se muestra en la Figura 2.1.

Figura 2.1.. Mundo virtual multiusuario


A medida que se ha mejorado y perfeccionado la tecnología de

construcción de entornos virtuales multiusuarios, se han desarrollado plataformas más extensas y sofisticadas, cuyas áreas de aplicación son mucho más serias que el simple entretenimiento- Es así como han surgido infraestructuras tan elaboradas y poderosas como la denominada CAVE, que se ha mencionada más arriba

2.2.1. APLICACIÓN DE LA PLATAFORMA CAVE. Un ejemplo de actualidad de las aplicaciones de la infraestructura CAVE lo constituye la tecnología Blue-C, desarrollada en el Eidgenössiche Technische Hochschule Zürich, es decir, el Instituto Federal de Tecnología de Suiza, más conocido por sus siglas en alemán, ETHZ, [2].

Figura 2.2. Visualización en ambiente RV inmersivo

(plataforma CAVE)

Sobre la base de esta tecnología, se ha desarrollado un ambiente que

permite la ―presencia a distancia‖, también llamada telepresencia, de los usuarios en un sitio de compras real. Esto es, el sitio de compras real es simulado en una computadora, desde donde puede ser accedido por los usuarios que estén conectados al sistema. La interacción de los usuarios con la escena virtual consiste en la selección de los productos ―directamente‖ en los estantes del sitio de compras, así como el proceso de compra, propiamente dicho. Los productos seleccionados y pagados son luego enviados a los hogares desde donde fueron solicitados. Los prototipos de estos desarrollos se denominan IN:SHOP. Tal desarrollo fue realizado con la colaboración de varios investigadores, entre quienes destacan los científicos de MultiMedia Laboratory (MML), adscritos al Departamento de Ciencias de la Computación de la Universidad de Zurich, Zurich, Suiza, [3].


En esta aplicación se combinan en un mismo ambiente virtual la adquisición de videos en tiempo real tomadas a partir de múltiples cámaras dentro del establecimiento comercial. Esta característica enfatiza la inmersión de los usuarios dentro de la escena y da más realismo a la interacción entre éstos y los objetos en el entorno virtual e incluso con otros usuarios dentro de la misma escena. Lejos de lo que pueda pensar, el interés de semejantes aplicaciones no es banal en absoluto, si se considera lo útil que puede resultar un sistema de compras a distancia de víveres y productos en general, para personas que vivan en regiones relativamente remotas y con pocas posibilidades de transporte hasta o desde los sitios de compra de suministros, bien sea por no disponibilidad de medios artificiales de transporte, o bien sea por limitaciones físicas, como consecuencia de enfermedades y, más aún, cuando sus necesidades deban ser atendidas durante un inclemente invierno 2.3. APLICACIONES MÉDICAS. El vasto mundo de la Medicina también es susceptible de ser incluido en las áreas de muy especial interés de la Teleoperación y de la Telerrobótica. Las primeras aplicaciones de la computación gráfica, así como de la Teleoperación y la Telerrobótica dentro del campo de la Medicina fueron y siguen siendo orientadas hacia la visualización de nuestro cuerpo a través del uso de cámaras endoscópicas y, más recientemente, de la adquisición y construcción de imágenes usando equipos altamente sofisticados de Tomografía por computadora (TAC) y de Resonancia Magnética (RM) Por otra parte, el interés no se ha quedado en la mera observación del cuerpo humano; también se han desarrollado equipos robóticos de asistencia quirúrgica, destinados a realizar con mayor precisión que la de un cirujano, incisiones craneales, osteotomías para corregir un sinnúmero de condiciones anormales congénitas, como luxaciones severas de cadera, entre otras.. La utilización de equipos de láser controlados por computadora para la realización de queratotomías (LASIK, Laser-Assisted In situ Keratomileusis) para la corrección de miopías y otras afecciones de la vista [4] constituye otra importante área de aplicación de la robótica a la Medicina.


2.3.1. Visualización y Análisis de Imágenes Computarizado En la Universidad de Iowa se han desarrollado aplicaciones para la

visualización en 3D del cerebro humano, basada en imágenes de Tomografñia por

computadora, sobre la plataforma InmersiveDesk usando CaveLib y OpenGL, como infraestructura.

Figura 2.3. Visualización 3D del cerebro humano, [5].

Además de la mera visualización de imágenes mediante el uso de

computaodras, está cobrando mucho auge el análisi de imágenes tridimensional, tomadas por Resonanica Magnética (MRI, Magnetic Resonance Imaging) y por Tomogradfía por computadora (CT, Computerized Tomography), como se puede ver en los recientes trabajos de Erik Vidholm en la Universidad de Uppsala, Suecia [6].

Figura 2.4. Vista axial del abdomen tomada con Resonancia Magnética (izquierda) y Tomografía por computadora del hígado. Nótese que se usa el método de trazado en vivo (live-

wire) con el cual la computadora indica el camino más corto entre un determinado punto-semilla, marcado en azul, y la posición actual del cursor, operado por el usuario. (Tomado de

[6], pp. 11,23)


En la Figura 2.4 se pueden apreciar dos imágenes. La primera, es una

vista axial del cerecito tramada con Resonancia Magnética. La segunda, es una vista del cerebro humano tomada con un tomógrafo computarizado; en esta última, se muestra una manera de cómo el usuario puede interactuar más directamente con la imagen para extraer mayor información de la misma, más allá de la mera visualización. En este caso, se hace uso de un método de trazado en vivo, que consiste en que la computadora determina y traza el camino real más corto entre dos puntos, escogidos interactivamente por el usuario.

Estas técnicas de visualización tridimensional de imágenes de interés

médico son aplicadas con cada vez mayor frecuencia en las distintas áreas de competencia de las especialidades médicas. Es así como se han desarrollado técnicas de visualización del fondo del ojo humano, y más concretamente, de la retina, por medio de tomografía por computadora. Esta técnica se conoce como Tomografía Óptica Coherente (Optical Coherent Tomography, OCT).

2.3.1.1. TOMOGRAFÍA ÓPTICA COHERENTE.

La Tomografía de coherencia Óptica es una nueva tecnología de imágenes no invasiva, sin contacto, transpupilar, la cual puede hacer imágenes de las estructuras de la retina in vivo, con una resolución de 10 a 17 micrones. La imagen de la sección transversal de la retina se obtiene por medio de la recopilación inversa (backscattering) de la luz, de manera análoga a la ultrasonografía B-scan. Las capas anatómicas de la retina pueden ser diferenciadas y también se puede medir el espesor de la retina [7].

Con la ayuda de la OCT se han podido describir patologías del segmento posterior. Esto incluye retinopatías diabéticas, huecos maculares, membranas epiretinales, edema macular cistoide, coroideopatía serosa central, problemas del disco óptico y glaucoma.


Figura 2.5. OCT de ojo del autor.

La Figura 2.5 muestra una OCT del ojo izquierdo del autor, utilizando el tipo de scanning conocido como espesor macular (macular thickness). En esta imagen se puede apreciar una vista transversal del ojo, y muestra los distintos estratos o capas del fondo del mismo. Se aprecia también la mácula y la fóvea. Los matices de colores permiten hacer notar las zonas más o menos irrigadas de la retina, lo que a su vez permite visualizar la densidad de células por capa. Esto, en conjunto con otras observaciones, permiten al especialista la determinación del status real de la retina del paciente para el tratamiento adecuado de severas enfermedades como las mencionadas anteriormente.

2.4. APLICACIONES DE TELEOPERACIÓN DE ROBOTS. Como ya se ha apuntado más arriba, el interés en diseñar y desarrollar aplicaciones de robots móviles teleoperador es propio de múltiples áreas de investigación, que incluyen especialidades dentro de un muy amplio rango de posibilidades. Desde la Medicina hasta la geología, desde la operación y control de satélites de comunicaciones hasta de vehículos y naves no tripuladas dirigidas a la investigación de planetas y otros cuerpos dentro del Sistema Solar, las aplicaciones de la Telerrobótica son innumerables. A continuación se mencionan algunas aplicaciones de la Telerrobótica que ejemplifican la utilidad de esta innovadora especialidad. 2.4.1. ROBOT MÓVIL EXPLORADOR PARA INSPECCIÓN GEOLÓGICA.

Típicamente, un geólogo que está explorando un sitio de interés

geológico tiene que caminar desde un sitio con un determinado rasgo geológico hasta otro. Esta labor no está exenta de riesgos, por lo que la implementación de un robot que permita la inspección visual a distancia sería de mucha ayuda para los geólogos.


Hasta ahora, se ha tratado de cumplir con esta tarea utilizando robots

móviles que son trasladados hasta sitios cercanos al rasgo geológico de interés, lo cual presenta dos inconvenientes. Primero, establecer la localización del rasgo de interés y, segundo, maniobrar el robot móvil hasta aquella localización. Las soluciones aportadas hasta ahora son susceptibles de errores de posición. Fundamentalmente, podemos ver a dónde queremos que el robot vaya, pero difícilmente `podemos cuantificar en donde se encuentra el objetivo o el propio robot. El desarrollo de robots manipuladores basados en visión sugiere un enfoque alternativo para los robots móviles exploradores.

En este sentido, se ha desarrollado [8] un sistema de control basado en

visión que permite al vehículo guiado a distancia (rover), conocido como Marsokhod, navegar dentro de un área de muestreo delimitada por algunas rocas o rasgos sobresalientes del terreno. En el desarrollo de este tipo de investigaciones, de han llevado adelante otras experiencias que han reportado beneficios no sólo al desarrollo de la Telerrobótica y de la Teleoperación, sino también al de la Geología. Es así como Wettergreen et alia, [9], han desarrollado experimentos para el control de navegación de equipos semejantes (ver Figura 2.6), orientados a la inspección y recolección de muestras de interés geológico en entornos hostiles.

Figura 2.6. Vehículo teleoperado de exploración

denominado Marsokhod (Tomada de [9]).

Este vehículo teleoperado de exploración, conocido como Marsokhod, fue

desarrollado por el Ames Research Center en Mountain View, California, y ha permitido a los científicos la exploración geológica remota de ambientes que simulan otros planetas, lo cual ha servido para preparar la realización de exploraciones reales en otros planetas, así mismo, ha sido de gran ayuda a los científicos en robótica para afinar aspectos técnicos de sus diseños.


El desarrollo de aplicaciones de este tipo incluye la posibilidad de implantar robots móviles controlados a distancia, basados en visión, que permitan explorar otros planetas y otros cuerpos estelares. El telescopio Hubble es, sin duda, un ejemplo destacado de la Teleoperación y la Telerrobótica.

Como comentario final de esta sección, vale la pena destacar el amplio uso de aplicaciones telerrobóticas para la navegación, control y operación de satélites de comunicaciones, como mencionan Bruce Campbell y William McCandless, en su obra Introducción a Ciencias Espaciales y Aplicaciones a Naves Espaciales [10], así como Bruce Elbert en su libro Manual de Aplicaciones de Satélites de Comunicaciones [11]. 2.5. CONCLUSIONES DEL CAPÍTULO

Como se ha podido ver someramente a través de los ejemplos descritos más arriba, las áreas de aplicación de la Telerrobótica y de la Teleoperación son innumerables.

Todas estas áreas entrañan un interés especial para cada una de las especialidades que han hecho uso de la Telerrobótica y de la Teleoperación, pero subyace un interés primordial, y que consiste en la obtención de más y más información no sólo de nuestro entorno en la Tierra, sino también, y de manera muy importante, de los entornos de otros planetas, cometas y satélites naturales cercanos al nuestro. En tanto mayor sea el conocimiento que podamos obtener de tales cuerpos siderales, tanto mejor podría ser el aprovechamiento de los recursos que ellos poseen. Así, nuevos materiales podrían desarrollarse a partir de elementos y que no existen en nuestro planeta.

La posibilidad de realizar experimentos en entornos espaciales, extraterrestres, ofrece toda una variedad de expectativas, sin dejar de mencionar la continuidad de la búsqueda de evidencias de otras formas de vida allende los límites de nuestro planeta.

El muy importante campo de la Medicina no deja de ser una de las áreas más favorecidas con este tipo de investigaciones. La exploración del fondo de nuestros océanos, mediante el uso de vehículos teleoperados, continuamente arroja nuevas formas de atacar enfermedades humanas que, hasta ahora, no tenían cura. Así mismo, tales exploraciones han permitido descubrir a la quimiosíntesis, la cual consiste en el aprovechamiento de nutrientes a partir de sustancias químicas provenientes de fuentes de aguas termales submarinos. En contraposición a la creencia generalmente aceptada hasta ahora, en el sentido de que la fotosíntesis era el único mecanismo de subsistencia de las especies vegetales, se ha comprobado que la quimiosíntesis sustenta formas de vidas,


hasta ahora, insospechadas, que pueden subsistir a temperaturas y condiciones increíbles, en completa ausencia de luz.

Por último, las áreas de entretenimiento, la enseñanza y aprendizaje, y hasta la ergonomía, tampoco escapan de ser susceptible de beneficiarse con nuevos desarrollos de aplicaciones, a partir de la utilización de la Telerrobótica y de la Teleoperación.


3. MODELADO Y SIMULACIÓN EN ENTORNOS VIRTUALES.

3.1. INTRODUCCIÓN

Para la construcción de mundos virtuales, es decir, escenarios de Realidad Virtual en donde puedan interactuar robots, se han diseñado varias herramientas, entre las cuales destacan por su popularidad el Lenguaje de Modelado de Realidad Virtual VRML (Virtual Reality Modeling Language) y eXtensible 3D, o X3D, desarrollado por Web3D Consortium, consorcio creado para el desarrollo de estándares en materia de gráficos 3D y comunicación en entornos de realidad aumentada. Ambas herramientas han llegado a establecerse como estándares en esta área de aplicaciones, siendo X3D un sucesor natural del VRML. La implementación de robots y la construcción de escenarios virtuales basados en la Internet no sólo implican la necesidad de lenguajes de programación gráfica. Es necesario, además, disponer de herramientas que permitan la representación matemática de tales robots, a través de ecuaciones que describan su cinemática tanto directa como inversa. Es por ello necesaria la utilización de métodos de representación matemática, tales como los llamados jacobianos y, por otro lado, el método Denavit-Hartenberg. Cada uno de estos métodos de representación de la cinemática de robots móviles posee sus pros y sus contras, por lo que serán analizados en este capítulo. Por último, para ciertas aplicaciones se hace necesario que los robots tengan apariencia humana. A tales robots con apariencia humana se le denomina humanoides. Se han llevado a cabo varios proyectos para describir las proporciones y medidas promedio de los seres humanos de acuerdo a su raza. Es así como se realizó el proyecto CAESAR [19], a partir del cual se han elaborado varios documentos y especificaciones que son utilizados a su vez para la descripción y construcción de humanoides en entornos virtuales, principalmente orietnados, hasta ahora, al diseño de juegos y simulaciones gráficas. Algunos detalles relativos a los humanoides y su incorporación a escenarios de Realidad Virtual son cubiertos en este capítulo.


3.2. LENGUAJE DE PROGRAMACIÓN VRML.

VRML fue desarrollado desde inicios de la década de los noventa. Ofrece muchísimas posibilidades para el diseño y construcción de escenarios virtuales, que incluyen desde la definición de los elementos geométricos propiamente dichos, hasta múltiples posibilidades de navegación dentro de la escena, con diferentes puntos de visualización (viewpoints), los cuales actúan como cámaras de vídeo colocadas en las posiciones deseadas por el diseñador. Así mismo, VRML ofrece rencores de proximidad, detectores de colisión y posibilidades de incorporar audio a la escena, para dar realismo y naturalidad.

En poco tiempo, VRML logró convertirse en un estándar reconocido por la Organización Internacional de Estándares (International Standard Organization, (ISO) y la Comisión Electrotécnica Internacional, (Internacional Electrotechnical Comission, IEC). Sus especificaciones técnicas están identificadas como ISO/IEC 14772-1 y pueden ser consultadas en [12].

Así mismo, el software que permite establecer interacción entre usuarios y escenas virtuales en la web desarrollada para trabajar conjuntamente con VRML y denominada Interfaz de Acceso Externo (External Access Interface, EAI) satisface las especificaciones técnicas identificadas como ISO/IEC 9126-1, relativas a la Ingeniería de Software y calidad de los productos. Estas especificaciones pueden ser consultadas en [14]

Los elementos geométricos pueden ser prefabricados (esferas, cubos, cilindros, conos, etc.), que sólo requieren ser adecuadamente parametrizados para especificar sus dimensiones; o pueden completa y arbitrariamente diseñados por el constructor de la escena, mediante la definición de contornos interiores y exteriores de las objetos en construcción y la unión de esos puntos mediante segmentos de líneas. Mientras mayor sea la cantidad de puntos definidos, mejor será la resolución del dibujo del objeto.

Los ejes del sistema de referencia global en VRML97 son a derechas con el eje X positivo indicando a la derecha, el eje Y positivo puesto vertical y el eje Z positivo apuntando hacia fuera de la pantalla, como muestra la Figura 3.1.

Figura 3.1. Ejes


El sistema de ejes en VRML97 funciona mediante un sistema "local" para cada objeto que se define, y un sistema "global" para poner en correspondencia a todos los objetos de un mismo entorno. Por lo tanto, si se define un objeto y no se le aplican transformaciones, su sistema de ejes "local" coincidirá con el sistema de ejes de mundo.

Evidentemente, las unidades son arbitrarias en un sistema de coordenadas 3D, pero, por convención, se entiende que las distancias lineales están en metros, los ángulos en radianes, el tiempo en segundos i los colores en RGB (Red-Green-Blue / Rojo-Verde-Azul).

Una descripción más detallada del lenguaje de programación VRML se puede encontrar en el Capítulo 5 – Apéndices de este trabajo.

3.3. LENGUAJE DE PROGRAMACIÓN X3D.

X3D es formato de archivo estándar abierto XML, que posibilita la comunicación de data 3D en tiempo real a través de todas las aplicaciones de usuario y las aplicaciones de rede. Este posee un gran conjunto de características para visualización de imágenes de ingeniería y de tipo científico, en general.

X3D es un software estándar escalable y abierto para definir y comunicar en tiempo real y para la modelación de de contenidos gráficos interactivos en tres dimensiones que incluyen efectos visuales y conductuales. Puede ser utilizado en varias plataformas de hardware y en un amplio rango de aplicaciones como CAD (Computer Arded Design), simulación visual, visualización médica, GIS (Geographical Information Systems), entretenimiento y presentaciones educativas y multimedios.

Como consecuencia del éxito y aceptación de VRML, los desarrolladores de software siguieron trabajando en pos de mejorar las características de este lenguaje de programación gráfico y esos esfuerzos devinieron en el desarrollo de X3D, acrónimo de eXtensible 3D. Este acrónimo enfatiza la potencialidad de esta herramienta para desarrollar y construir escenas en tres dimensiones, asumiendo como base el VRML, por lo que paso a convertirse en un estándar también reconocido por la ISO y la IEC. Sus especificaciones técnicas están identificadas como ISO/IEC 19775, las cuales pueden ser consultadas en [14]. La primera parte de estas especificaciones, 19775-1, describen todo lo concerniente al lenguaje de programación X3D, en tanto que la segunda parte, 19775-2, describe el software de interfaz con usuarios de la web, el cual se denomina Interfaz de Acceso a Escena (Scene Access Interface, SAI), el cual pasó a ser el sucesor natural de EAI. Las especificaciones técnicas pueden ser consultadas en [15][16].


X3D provee tanto la codificación en XML como la interfaz para construcción de escenas conocida por sus siglas SAI (Scene Access Interface), para permitir que, tanto las aplicaciones web como las no-web, incorporen data 3D, presentaciones y controles dentro de contenidos no-3D.

X3D acepta archivos de definición de mundos virtuales creados en VRML; de hecho, considera a VRML como un subconjunto.

Existen varios navegadores (browsers) que permiten visualizar y manipular los objetos contenidos dentro e un mundo virtual. Entre ellos se encuentra Cortona Browser, realizado por el mismo equipo de diseño de VRML, es decir, ParallelGraphics, Inc. Por otra parte, el navegador Octagon Player es adecuado para visualizar y trabajar con archivos X3D.

A diferencia del VRML, que se puede considerar un lenguaje autónomo para la construcción de mundos virtuales, X3D, en tanto que más capaz y poderoso, requiere de toda una plataforma de trabajo.

Una descripción más detallada del lenguaje de programación eXtensible 3D, X3D, se puede encontrar en el Capítulo 4 – Apéndices de este trabajo.

3.4. CONSIDERACIONES PARA LA IMPLEMENTACIÓN DE UNA INTERFAZ USUARIO/ROBOT EN UN ENTORNO VIRTUAL.

Para afrontar el desarrollo de una interfaz entre usuarios y robots dentro de una escena virtual, es necesario entender la interacción entre los mismos y cómo ésta se puede implementar. Ya se ha mencionado que existen herramientas de software que permiten establecer dicha interrelación, a través de eventos.

Ante todo, se debe definir el robot, para lo cual es necesario definir los parámetros de entrada y salida, así como las propiedades que describen la instancia o réplica de ese robot. Es necesario revisar la teoría robótica.

En el caso de un robot industrial, el cual básicamente consiste de un brazo móvil que permite manipular una herramienta dentro de un espacio limitado, se debe definir el número de segmentos que conforman el brazo móvil. Los segmentos se encuentran conectados por articulaciones (joints), las cuales definen a su vez los grados de libertad del robot. Un grado de libertad representa la posibilidad de que el robot se mueva en una determinada dirección. Por ejemplo, si las articulaciones permiten movimientos rotacionales circunscritos dentro de un plano X-Y (2D), se habla de que posee un grado de libertad. Si los movimientos se circunscriben dentro de una esfera imaginaria con centro en el origen del sistema de referencia asociado a la articulación, se dice que posee dos grados de libertad. Un tercer grado de libertad es necesario para que el robot alcance cualquier punto dentro de la totalidad


de su espacio de trabajo. La posibilidad de avanzar y retroceder en cualquiera de las direcciones, así como de rotar los segmentos que lo conforman, resultan en un total de seis grados libertad.

3.4.1. CINEMÁTICA DIRECTA E INVERSA.

Se puede utilizar diversos esquemas de cálculo para determinar la nueva posición que ocuparía un objeto o alguna de sus partes dentro de la escena. Las partes articuladas a la que está bajo consideración deben moverse consecuente y armónicamente con ésta, para lograr naturalidad en la secuencia de movimientos. Todo esto está comprendido en el estudio de la cinemática de los objetos en escena.

Los métodos de cálculo de la cinemática de los avatares comprende el uso de jacobianos sobre cada una de sus articulaciones, respecto de los tradicionales sistemas de referencia cartesianos (X,Y,Z), lo cual resulta en una gran cantidad de cálculos que ralentizan la actualización de las posiciones de los avatares dentro del mundo virtual. Es por ello que se ha hecho más popular el uso del método de descripción y cálculo cinemático, conocido como Denavit-Hatenberg, el cual consiste en describir cada articulación en función de los ángulos que forma cada eje longitudinal de movimiento de las partes del avatar con los ejes cartesianos locales (referidos a cada articulación).

3.4.1.1. Jacobianos.

El análisis de la cinemática de un robot móvil, tanto directa como inversa, es susceptible de ser efectuado a través del uso de matrices de transformación conocidas como jacobianos, en honor a su propulsor….

El uso de jacobianos, aunque constituyen una herramienta de análisis muy poderosa, puede no resultar muy amigable y conducir a complicadas formulaciones cuya solución no se puede garantizar de antemano.

En esta sección, se explicará someramente la utilización de jacobianos para describir matemáticamente las variaciones de posición y de velocidad de un robot móvil, tanto desde el punto de vista directo, es decir, para el caso de la posición, dadas las coordenadas de cada articulación del robot, calcular las coordenadas de la posición del extremo efector del mismo, así como desde el punto de vista inverso, esto es, dado un determinado punto dentro del espacio de trabajo del robot, calcular las posiciones de cada uno de sus elementos, para que el extremo efector se posicione en el referido punto.

Vale decir que los cálculos requeridos por la cinemática inversa son, en general, mucho más complicados que los implicados en la cinemática directa. De


hecho, pudiera haber infinitas soluciones a este problema o, incluso, pudiera no existir ninguna, por cuanto, sin importar cuál configuración asuman los elementos del robot, existen puntos de su espacio de trabajo imposible de alcanzar por limitaciones impuestas por su propia geometría.

3.4.1.1.1. Cinemática Directa usando Jacobianos.

Para describir matemáticamente y analizar la cinemática de un robot móvil mediante el uso de jacobianos, es necesario efectuar una serie de transformaciones, a base de traslaciones y rotaciones de sistemas de ejes cartesianos.

Estas transformaciones dependen directamente de la geometría del robot a describir, incluyendo el número de ruedas fijas y direccionables.

A manera de ejemplo, para un robot con tres ruedas, una de ellas direccionables, como el que se muestra a continuación,

Figura 3.2. Modelo de un robot móvil de tres ruedas.

se plantean las correspondientes transformaciones, las cuales se muestran a continuación.


Figura 3.3. Matrices jacobianas del robot móvil de tres ruedas.

Nótese que se han incluido las derivadas respecto del tiempo, con lo cual se puede efectuar el análisis de velocidad.

3.4.1.1.2. Cinemática Inversa usando Jacobianos.

Como ya se ha revisado en la sección previa, la cinemática directa consiste en calcular la velocidad de un vehiculo o robot en función de las aportaciones de velocidad que dan cada una de las ruedas del mismo.

Paralelamente, se plantea el problema inverso, el cual consiste en obtener las velocidades de cada una de las ruedas de tal manera que el robot muestre un determinado estado de movimiento. Esto es conocido como la cinemática inversa.

Seguidamente se muestra un flujograma que permite visualizar las opciones que se pueden presentar durante la aplicación de jacobianos para describir la cinemática inversa de un robot.


Figura 3.4. Jacobiano Inverso del robot móvil de tres ruedas.

Como se puede apreciar en el flujograma de la Figura 3.4, existe la posibilidad de plantear un sistema de ecuaciones cuya solución no sea consistente, es decir, que sea físicamente imposible de materializar.

3.4.1.2. Descripción Del Robot En Términos De Los Parámetros De Denavit-Hartenberg.

Para describir un robot desde el punto de vista matemático, se puede hacer uso de los parámetros conocidos como Denavit- Hartenberg. Este conjunto de parámetros permite describir todas y cada una de las articulaciones y es la base para cualquier cálculo cinemático.

La descripción de las articulaciones y segmentos de un robot por medio de los parámetros de Denavit-Hartenberg utilizan la regla de la mano derecha, comúnmente utilizada para la determinación de ejes y movimientos vectoriales. Esta regla se ilustra en la Figura 3.5.


Figura 3.5. Regla de la mano derecha (rmd).

Las Figuras 2-58 a 2-61 muestran la ubicación de estos parámetros para un robot con tres articulaciones.

Figura 3.6. Ubicación de los .3,2,1, ii

Figura 3.7. Ubicación de los .3,2,1, iai


Figura 3.8. Ubicación de los .3,2,1, ii

Figura 3.9. Ubicación de los .3,2,1, idi

Como se ve en las Figuras 2-58 a 2-61, hay cuatro valores por cada

articulación: a, d, y . Se definen además valores máximo y mínimo para la rotación, min y max. En vista de que estos valores no cambian después de la replicación (instanciación) del robot, en VRML/X3D se pueden manejar estos seis valores a través de un campo de seis valores de tipo real (floating point) para cada uno de los parámetros.

Una vez que se han definido los parámetros de Denavit-Hartenberg para describir las articulaciones del robot, es preciso determinar la matriz de transformación que permitirá efectuar los cálculos de la cinemática inversa. Esto se muestra en la Figura 3.10.


Figura 3.10. Cálculo de la matriz de Transformación, T.

A partir de la matriz de transformación T, se puede obtener los valores de posición y rotación necesarias para alcanzar un determinado punto dentro del espacio de trabajo del robot (cinemática directa) y, por adecuados manejos algebraicos, también se puede dar a la componente de cálculo cinemática una determinada posición en el espacio y dejar que ésta calcule los valores de posición y rotación correspondientes para que el robot alcance ese punto objetivo. (cinemática inversa). Todo esto se basa en

0* STSn

Donde:

nS es el origen del sistema de referencia del extremo del segmento de robot,

0S es el origen del sistema de referencia de la base del robot.

3.4.1.3. Análisis comparativo de los métodos de cálculo cinemático.

Como se ha descrito en las dos secciones anteriores, en donde se describen los métodos de cálculo de la cinemática directa e inversa según la descripción por jacobianos y por el método de Hartenberg-Denavit, se pueden establecer puntos importantes de comparación entre estos dos métodos, para seleccionar cuál sería más conveniente.

En primer lugar, la utilización de jacobianos es más pesada, desde el punto de vista de la cantidad de cálculo requerido para obtener las derivadas (para la cinemática directa) e integrales (para la cinemática inversa), así como el manejo de matrices de transformación no necesariamente cuadradas, lo cual puede conducir a descripciones matemáticas sin solución o con multitud de soluciones. Por contraste, el método Denavit-Hartenberg permite una descripción más estable desde el punto de vista de la solución.


Por otra parte, el cálculo de la inversa de una matriz es muy sensible a la propagación de errores de aproximación y redondeo, lo que pudiera resultar en errores importantes de posicionamiento de las articulaciones del robot dentro de la escena virtual. Por otra parte, el tiempo de procesamiento es largo en comparación al requerido para la realización de operaciones aritméticas sobre matrices. Este tiempo de procesamiento considerablemente largo pudiera notarse en la falta de naturalidad en los movimientos de los robots, más aun cuando éstos simulan seres humanos, es decir, humanoides.

En el análisis cinemático basado en jacobianos se plantean limitaciones importantes

que deben ser tomadas en cuenta. Entre estas limitaciones están:

la convención de que el robot se mueve por una superficie plana. Debido a

esto, la consideración de cualquier inclinación en la superficie de

desplazamiento implicaría el replanteamiento de todas las ecuaciones.

Por otra parte, el robot bajo estudio no debe tener elementos flexibles

(incluidas las ruedas).

Las ruedas poseen 0 o 1 grado de direccionamiento, i.e., o son fijas en

una única dirección o, a lo sumo, pueden desviarse en una sola

dirección.

Por último, se asume que no hay fricción.

En segundo lugar, todos los cálculos involucrados en la utilización del método de Denavit-Hartenberg son operaciones aritméticas simples, como sumas y productos. Por otra parte, debido a la forma en que se establecen las relaciones entre los elementos y articulaciones de un robot, es mucho más fácil y rápido obtener las coordenadas de cada articulación, referidas al sistema de ejes cartesianos asociado a cualquiera otra articulación e incluso, respecto de la base del robot considerado.

Un punto indudablemente a favor de la descripción mediante el uso de jacobianos es la posibilidad que ofrece de analizar no sólo la posición sino la velocidad del robot, lo cual no se puede dejar de lado en el diseño de robots móviles físicos.

De acuerdo a lo antes explicado y considerando que en el diseño y construcción de robots virtuales se tiene mayor interés en el posicionamiento y en variaciones de posición de un objeto respecto de otro y de su entorno, no así en consideraciones velocidad, se considera el uso del método de Denavit-Hartenvberg para la descripción de los robots dentro de escenas virtuales y para el cálculo de la cinemática tanto directa como inversa.


3.4.2. CONSIDERACIONES SOBRE LA IMPLEMENTACIÓN DE UN ROBOT EN UNA ESCENA VIRTUAL BASADA EN LA WEB.

Un robot virtual dentro de una escena en la web puede ser manipulado a través de eventos. Estos eventos pueden ser generados desde la misma escena en la web, como producto, por ejemplo, de la detección de colisiones del robot con los objetos dentro de la escena, o por el vencimiento de un determinado lapso de tiempo controlado por un temporizador: también pueden ser generados por el usuario que manipula al robot, mediante, por ejemplo, la introducción de una nueva posición que éste quiera que alcance el avatar.

En la terminología de las herramientas de software que permiten la implementación y manejo de estos eventos, tales como el Scene Access Interface, o SAI, los eventos generados en la escena virtual son denominados EventOut mientras que los generados por el usuario son llamados EventIn.

A continuación, se describirá el uso de estos eventos para poder interactuar con los robots dentro de una escena virtual basada en la web.

Hay dos maneras diferentes de mover un robot a una nueva posición dentro de una escena virtual: Los valores de los parámetros pueden ser introducidos directamente, lo cual afectaría la posición y la rotación del robot; o, en forma más flexible, se introduce una posición o una rotación objetivo (es decir, aquella que se pretende que el robot asuma) y se deja al robot efectuar los cálculos y establezca los valores resultantes en las respectivas articulaciones para obtener la posición final deseada.

Los estados de las articulaciones son representados por un vector de seis elementos MFFloat, y en lugar de una matriz de 3x4, se puede utilizar los tipos de datos SFVec3f y SFRotation de VRML/X3D para los valores de rotación y posición.

Cuando se recibe un eventIn, los valores modificados serán enviados a un eventOut nuevamente, por lo que el comportamientos del robot es como sigue:

1. IN set_position > OUT joint_changed

2. IN set_rotation > OUT joint_changed 3. IN set_joint > OUT position_changed + OUT rotation_changed

Esto quiere decir que el valor de la nueva posición, almacenada en set_position, es transferida hacia la articulación (previa afectación por el cálculo cinemático), en joint_changed.

A continuación se explicarán brevemente algunos prototipos de software propuestos por Martin Röhrmeier, [17] y [18], para la implementación de un robot basado en la web, utilizando VRML y EAI, como interfaz de usuario. La adaptación de estos prototipos a X3D como herramienta de construcción, utilizando SAI como


interfaz de usuario, considerando que ésta constituye la plataforma estándar de desarrollo de este tipo de aplicaciones, luce relativamente fácil de realizar, por lo que se propone como parte de un trabajo de investigación de carácter más práctico, orientado a la implementación de aplicaciones más que a la documentación del estado del arte de las Interfaces para Aplicaciones Telerrobóticas y de Teleoperación, como en este caso.

El prototipo del robot propuesto por M. Röhrmeier implementado en VRML se puede apreciar en la Figura 3.11. Los parámetros adicionales del robot contienen el URL del archivo VRML/X3D para cada uno de los segmentos.

PROTO Robot [

eventIn SFVec3f set_position

eventIn SFRotation set_rotation

eventIn MFFloat set_joint

eventOut SFVec3f position_changed

eventOut SFRotation rotation_changed

eventOut MFFloat joint_changed

field MFFloat a [0,0,0,0,0,0]

field MFFloat d [0,0,0,0,0,0]

field MFFloat alpha [0,0,0,0,0,0]

field MFFloat theta [0,0,0,0,0,0]

field MFFloat min [0,0,0,0,0,0]

field MFFloat max [0,0,0,0,0,0]

field MFString arm []

Figura 3.11. Definición del prototipo en VRML/X3D

La tarea de implementación del robot se divide en tres problemas separados: la visualización del robot, para mostrar el modelo del robot sobre la pantalla. El cálculo cinemático, para convertir posiciones y rotaciones en valores que afectan a cada articulación, así como estados de las articulaciones a ser convertidos en posiciones y rotaciones, haciendo uso de cinemática inversa y viceversa; y, finalmente, una interfaz que posibilite al usuario mover el robot en seis grados de libertad utilizando un dispositivo sencillo de 2D, como un ratón. El flujo de datos entre las componentes explicadas se muestra en la Figura 3.12.


Figura 3.12. Flujo de Datos entre componentes.

La componente de visualización es quizás la más interesante. Para implementarla en VRML/X3D es necesario considerar que cada segmento del robot se mueve en un sistema de coordenadas que está determinado por la posición del segmento previo

Figura 3.13. Estructura de un Segmento del Robot en VRML/X3D

Esta cadena puede ser modelada mediante un árbol de nodos, donde cada

nodo de un segmento es hijo del nodo previo. Las distancias para ensamblar el robot son tomadas de los parámetros Denavit-Hartenberg, los cuales también han de ser pasados a esta componente de visualización.


Se puede observar una ruptura en el flujo de datos del modelo (Figura 3.13). El valor de Joint controla el robot en cualquier segmento rotando la respectiva articulación. Esta tarea debe pertenecer a la componente de interfaz de usuario, por cuanto ya el árbol de eventos está contenido en ella.

PROTO rob_geo [



field MFFloat a

[0,0,0,0,0,0]

field MFFloat d

[0,0,0,0,0,0]

field MFFloat alpha

[0,0,0,0,0,0]

field MFFloat theta

[0,0,0,0,0,0]

field MFFloat min

[0,0,0,0,0,0]

field MFFloat max

[0,0,0,0,0,0]

]

Figura 3.14. Definición del prototipo rob_geo

Los eventos generados son directamente enrutados hacia la articulación y también serán enviados hacia el script, el cual escribirá nuevamente los valores dentro de un arreglo. Este arreglo es la salida del módulo denominado rob_geo, cuyo prototipo aparece a continuación.

3.4.2.1. Componente de Cálculo Cinemático.

Esta componente es la más complicada desde el punto de vista matemático, Sus funciones básicas son convertir posiciones y rotaciones en valores de articulación y, viceversa, obtener la posición y rotación correspondiente a un determinado valor de articulación, es decir, a una posición cualquiera de un punto del robot dentro de su espacio de trabajo.


Un posible prototipo para este módulo se muestra a continuación.

PROTO rob_kin [







field MFFloat a

[0,0,0,0,0,0]

field MFFloat d

[0,0,0,0,0,0]

field MFFloat alpha

[0,0,0,0,0,0]

field MFFloat theta

[0,0,0,0,0,0]

field MFFloat min

[0,0,0,0,0,0]

field MFFloat max

[0,0,0,0,0,0]

]

Figura 3.15. Definición del prototipo rob_kin

3.4.2.2. Componente de interfaz de usuario.

Esta componente posee una colección de objetos 3D con sensores que permiten al usuario manipular al robot dentro de su entorno virtual. El movimiento de cualquiera de estos objetos implica la salida de un valor de posición y/o rotación, que son pasados al módulo de cinemática inversa. Como los puntos objetivos pueden caer fuera del entorno de trabajo del robot, esos valores son siempre retornados al módulo de interfaz con el usuario para su posible corrección. El prototipo es bastante sencillo y se muestra a continuación.

PROTO rob_ctrl [





]

Figura 3.16. Definición del prototipo rob_kin.


3.4.2.3. Modelado y Animación de Humanoides.

Dentro de la área de aplicaciones de la Telerrobótica y los entornos virtuales está la modelación y simulación de robots o avatares que semejan a seres humanos, también llamados humanoides.

En vista de la amplísima variedad de industrias interesadas en las medidas del cuerpo humano, que van desde las encargadas de diseño de vestimenta, hasta diseño de artefactos ergonómicos, como asientos para oficinas, vehículos y todo tipo de medios de transporte y de maquinaria operada por seres humanos, a lo lago de la década de los noventa un considerable número de empresas levantaron una base de datos, desarrollada a partir de mediciones corporales de unos 2500 individuos norteamericanos y otros tantos canadienses y europeos, a fin de elaborar un conjunto de mediciones estándares. Este proyecto fue denominado CAESAR (Civilian American and European Surface Anthropometry Resource) Recurso Antropométrico de la Superficie de Civiles Europeos y Americanos) [19], el cual terminó y publicó resultados en 1998.

Estas mediciones han sido tomadas por muchos investigadores para desarrollar infinidad de aplicaciones destinadas al uso por parte de seres humanos. El grupo de trabajo de X3D y del NIST (National Institute of Standards and Technology) [20], también han hecho uso de esta base de datos para el diseño de humanoides dentro de entornos virtuales. A continuación se mencionan algunas consideraciones y observaciones que se derivan de la base de datos CAESAR, aplicada a la modelación de humanoides, los cuales son referidos como H-Anim, en la terminología de X3D.

En la Tabla 3.1, aparece una lista de los puntos característicos del H-Anim. Los puntos característicos son derivados de los usados en el proyecto CAESAR, con los nombres modificados para que sean conformes con los usados en la nomenclatura convencional y en el resto del documento ISO-7250, [21].

Este documento contiene un conjunto de medidas humanas ampliamente usadas en investigaciones antropométricas. La Tabla 3.1 contiene listas de puntos en tres dimensiones que son característicos que no tienes equivalentes o no se solapan con los de dicho documento y fueron derivados de estudios antropométricos realizados bajo el proyecto CAESAR. Hay unos pocos términos comunes a las especificaciones H-Anim, proyecto CAESAR y al documento ISO -7250, que han sido derivados anatómicamente. Estos términos tienen la siguiente identificación según el documento ISO-7250.


acromion,

cervicale / vértebra cervica

metacarpianos s

sellion,

tragion,

la continuación de la espina escapular para formar la articulación acromio-clavicular [22] la vértebra del cuello.

huesos de la mano que articulan con las falanges (ver Figura 3.17)

corresponde con la unión de óseo-cartilaginosa del dorso de la nariz. [23].

un punto cefalométrico ubicado justo por encima de la prominencia enfrente de abertura externa del oído,

denominada tragus. Se encuentra 1 o 2 mm debajo de la hélice de la oreja.

Figura 3.17. Metacarpianos (mano izquierda

Las posiciones de los puntos característicos del H-Anim están indicadas en la Figura 3.18, utilizando la numeración de los puntos de la Tabla 3.1.


1 Sellion

2 Rt. Infraorbitale

3 Lt. Infraorbitale

4 Supramenton

5 Rt. Tragion

6 Rt. Gonion

7 Lt. Tragion

8 Lt. Gonion

9 Nuchale

10 Rt. Clavicale

11 Suprasternale

12 Lt. Clavicale

13 Rt. Thelion/Bustpoint

14 Lt. Thelion/Bustpoint

15 Substernale

16 Rt. 10th Rib

17 Rt. ASIS

18 Lt. 10th Rib

19 Rt. Iliocristale

21Rt. Trochanterion

22 Lt. Iliocristale

23 Lt. Trochanterion

24 Cervicale

25 10th Rib Midspine

26 Rt. PSIS

27 Lt. PSIS

28 Waist, Preferred, Post.

29 Rt. Acromion

30 Rt. Axilla, Ant

31 Rt. Radial Styloid

32 Rt. Axilla, Post.

33 Rt. Olecranon

34 Rt. Humeral Lateral Epicn

35 Rt. Humeral Medial Epicn

36 Rt. Radiale

37 Rt. Me

tacarpal Phal. II

38 Rt. Dactylion

39 Rt. Ulnar Styloid

40 Rt. Metacarpal-Phal. V

41 Lt. Acromion

42 Lt. Axilla, Ant

43 Lt. Radial Styloid

44 Lt. Axilla, Post.

45 Lt. Olecranon

46 Lt. Humeral Lateral

Epicn

47 Lt. Humeral Medial Epicn

48 Lt. Radiale

49 Lt. Metacarpal-Phal. II

50 0 Lt. Dactylion

51 Lt. Ulnar Styloid

52 Lt. Metacarpal-Phal. V

53 Rt. Knee Crease

54 Rt. Femoral Lateral

Epicn

55 Rt. Femoral Medial Epicn

56 Rt. Metatarsal-Phal. V

57 Rt. Lateral Malleolus

58 Rt. Medial Malleolus

59 Rt. Sphyrion

60 Rt. Metatarsal-Phal. I

61 Rt. Calcaneous, Post.

62 Rt. Digit II

63 Lt. Knee Crease

64 Lt. Femoral Lateral

Epicn

65 Lt. Femoral Medial Epicn

66 0 Lt. Metatarsal-Phal. V

67 Lt. Lateral Malleolus

68 Lt. Medial Malleolus

69 Lt. Sphyrion

70 Lt. Metatarsal-Phal. I

71 Lt. Calcaneous, Post.

72 Lt. Digit II

73 Crotch

Tabla 3.1 — Puntos característicos, [19].


Figura 3.18. Puntos característicos sobre el cuerpo humano, [24].

La Figura 3.19 muestra una representación de figuras humanas basadas en la descripción contenida en el documento ISO-7250, [21].


Figura 3.19. Representación típica de humanoides, en términos de la descripción contenida en

documento ISO-7250.

3.5. CONCLUSIONES DEL CAPÍTULO. En este capítulo, se han revisado algunas maneras de describir matemáticamente la cinemática, tanto directa como inversa, de un robot móvil. Aunque los jacobianos ofrecen una descripción muy completa de toda la cinemática, su utilización involucra cálculos pesados y susceptibles a errores de aproximación y redondeo que pueden derivar en errores considerables en la representación y naturalidad de los movimientos de los robots. Por esta razón, aparte de otras de carácter más intuitivo, se sugiere la utilización del método de representación Denavit-Hartenberg. Igualmente, se revisaron dos lenguajes de programación utilizados en la representación gráfica de los robots en escenas virtuales. Estos son VRML y X3D. En vista de que X3D reconoce el formato de archivos de VRML y, además, incropora otros elementos que enriquecen la escena y los objetos que aparecen en ella, se sugiere la utilización de éste como herramienta para la construcción de escenas virtuales basadas en la web. Al final del capítulo se incluyen detalles de la representación de humanoides en escenas virtuales. Esta representación está basada en las medidas y proporciones del cuerpo humano compiladas en el docuemtno ISO-7250.


La relación entre descripciones matemáticas, lenguajes de programación gráfica y representación de humanoides en escenas virtuales viene dada por que, desde el punto de vista mecánico, el soporte del cuerpo humano lo constituye un conjunto de articulaciones y vínculos (huesos) que conforman el esqueleto. Estos vínculos y articulaciones se deben representar matemáticamente para efectos de reproducir sus movimientos dentro de un ordenador. Una vez que se tiene la representación matemática, ésta debe ser convertida en un código que pueda ser interpretado por el ordenador, el cual, además, deberá mostrar gráficamente las diferentes posiciones que deba asumir el humanoide, de acuerdo a los cálculos derivados del modelo matemático. Por último, la apariencia humana de este humanoide se la da el conocimiento y utilización de las medidas y proporciones de los seres humanos, aportadas por documentos como el ISO-7250, el cual a su vez se basó en el proyecto CAESAR.


Página Intencionalmente dejada en blanco


4. DISPOSITIVOS HÁPTICOS.

4.1. INTRODUCCIÓN.

Háptico, etimológicamente hablando, proviene de una palabra de origen griego que significa ―tocar‖, y se refiere a la modalidad del sentido del tacto, en la misma manera en que la ―visión‖ se refiere al sentido de la vista. Con el crecimiento en continuo ascenso de la tecnología, los dispositivos hápticos han abierto nuevos caminos a aplicaciones de muy diversa naturaleza, como: simulación/realización de cirugía, rehabilitación, toda suerte de ingenios móviles (como teléfonos celulares, aparatos de audio y vídeo y hasta dispositivos médicos más sofisticados como sensores y monitores de distintas partes del cuerpo humano; la actividad militar e incluso juegos, no escapan de las áreas de aplicación estos dispositivos,. Recientes investigaciones sobre análisis de imágenes médicas tomadas usando Tomografía por Computadora (CT), (Computerized Tomography) y por Resonancia Magnética (MRI, Magnetic Resonance Imaging), haciendo uso de dispositivos hápticos, permitirán en un futuro cercano la implementación de equipos especializados que ofrecerán a los médicos la posibilidad de ―sentir‖ los órganos que hayan sido escaneados para propósitos de diagnóstico de enfermedades, [6].

Otra área de aplicación no menos interesante de la háptica, aunque un poco

más frívola, es la planteada recientemente por Motorola y LG, las cuales están incorporando detalles hápticos a las pantallas de sus nuevos teléfonos móviles, para dar al usuario la sensación de estar ―pulsando‖ una tecla, cuando simplemente posan un dedo sobre un determinado recuadro sobre la superficie de una pantalla plana.

Naturalmente, la implementación de estas cualidades hápticas, requieren

poder cuantificar la percepción táctil de los objetos por parte de los seres humanos. Muchos esfuerzos se han dedicado al logro de tal objetivo. Un ejemplo importante de estos esfuerzos lo constituye, sin duda, el trabajo de E. Fasse y sus colaboradores [35], quienes han propuesto la utilización de la geometría de Riemann para cuantificar dicha percepción.


4.2. ALGUNAS ÁREAS DE APLICACIÓN E INVESTIGACIÓN.

En esta sección se describirán superficialmente algunas aplicaciones de los dispositivos hápticos, en áreas tan diversas como la Música, la Medicina y hasta la Geología.

4.2.1. Edición de Música.

Las tareas de edición de música también están siendo objeto de mejoras a través del uso de dispositivos hápticos, a través de los cuales se haga ―sentir‖ al músico la realimentación de los efectos de su manipulación sobre el sonido bajo edición, [25].

Los dispositivos hápticos para tareas de edición musical consisten en una

variedad de iconos en pantallas de visualización del material en edición, que le indican al editor efectos especiales como:

Perillas a resorte (spring-loaded knobs).

Diversos niveles de amortiguamiento.

Fuerzas suministradas en forma de rampa entre los puntos a partir de los cuales el sonido puede resultar desagradable (onsets) y los puntos de balance (offsets).

Uso de texturas hápticas para describir sonidos.

El resultado de la aplicación de dispositivos hápticos a la edición de música es una mayor percepción por parte del músico de los efectos de la manipulación del sonido, a los fines de lograr un producto mejor elaborado que satisfaga y complazca al oyente.

Se han diseñado prototipos que consisten en un software de navegación de

sonido que puede ser controlado con un ―ratón‖ vibro-táctil o con una perilla háptica, [25].

4.2.2. Caracterización de Patrones de Perfusión de la Sangre en la punta de un dedo.

Hay un creciente interés dentro de la área de la Realidad Virtual y de la

Háptica en entender cómo se perciben y cómo se ejercen fuerzas en las puntas de los dedos humanos, para la simulación de personas dentro de escenarios virtuales, además de aquellas más tradicionales como la Medicina y la Robótica [26][28][29][30].


Es sabido que cuando la punta de un dedo es presionado contra una superficie, el estado de la hemodinámica del dedo es afectada de manera similar en humanos comunes. La fuerza normal, la fuerza de corte y la extensión/flexión del dedo resultan en patrones visiblemente diferentes del volumen o perfusión de la sangre debajo de la uña. Estos patrones de perfusión de sangre pueden ser utilizados no sólo para monitorear el estado del dedo, sino también para entender cómo interactúa la uña con el hueso y con los tejidos circundantes.

Se podrían diseñar dispositivos hápticos que indicaran a un entorno

virtual cuánta presión está ejerciendo el dedo sobre una determinada superficie, pero, además, para hacer que el usuario ―perciba‖ una sensación correspondiente a dicho nivel de presión.

Los resultados del este tipo de estudios deviene en el desarrollo de guantes tipo exoesqueletos, dispositivos con gatillos, etc. Estos dispositivos interactúan directamente con la escena virtual, para una variedad de aplicaciones que van desde juegos en entornos virtuales hasta asistentes robóticas para la cirugía.

Figura 4.1. Variables de interés de la mano humana (izq.). Arreglo para fotografiar el parón de

coloración de la uña al pulsar un botón. (Tomado de [27])

La realimentación en estos casos no se limita sólo a la sensación de fuerza

en ambos sentidos, sino que también se puede mostrar el cambio de coloración de la punta del dedo como efecto de aquella.


4.2.3. Exploración Háptica para determinar la Orientación de una Superficie de acuerdo a su Textura.

Otra área de investigación afín al estudio y entendimiento de los

patrones de perfusión de la sangre en la punta de un dedo es la determinación de la orientación de una superficie de acuerdo a la variación en la orientación de su textura, [24]. La investigación sobre la rugosidad de la superficie ha tendido a involucrar el uso de superficies absolutamente regulares (como punto sen relieve, patrones de puntos u orificios igualmente espaciados hechos a máquina, etc.) o estocásticamente distribuidos como el papel de lija. Sin embargo, las superficies regulares pueden confundir la percepción de la textura con el conocimiento previo del perceptor o la expectativa de regularidad. Conocer a priori que la superficie es regular puede afectar la subsiguiente exploración de la superficie, por ejemplo, auspiciando un muestreo parcial, o puede afectar la precisión perceptiva (cualquier variación en la propiedad general de la superficie puede ser ignorada), o incluso puede afectar ambas. Por lo tanto, la comparación de texturas de configuraciones de más alto orden tienen el poder de probar las capacidades del sistema háptico para extraer texturas en una forma que las texturas regulares no pueden. (H Hughes, 2006), [30].

4.2.4. Determinación de la dirección de una fuerza, usando dispositivos hápticos.

Otra área de investigación muy interesante tiene que ver con la capacidad

de la gente para discriminar la dirección de una fuerza aplicada a la punta de sus dedos. En este sentido, los investigadores Barbagli, F., Salisbury, K., Ho, C., Spence, C., y Tan, H, de las universidades de Oxford, Standford y Purdue, [31][32], han llevado a cabo importantes experimentos para determinar umbrales de percepción de los cambios de dirección de las fuerzas aplicadas. Utilizando un dispositivo de realimentación de fuerza háptico, conocido como PHANToM (SensAbleTechnologies, Inc., Woburn, MA, USA), estos investigadores montaron un experimento con 25 participantes (entre los cuales había usuarios expertos y moderados, así como inexpertos en el uso de dispositivos hápticos), quienes debieron hacer uso del dedal propio del Phantom en su dedo índice, para ser sometidos a fuerzas en el rango de 0 a 2 Newtons, dirigidas en cinco direcciones diferentes (Arriba, derecha, izquierda, diagonalmente a la derecha y diagonalmente a la izquierda), pudiendo establecer, entre otras cosas, que:

a. El umbral de discriminación promedio de la dirección de una fuerza aplicada a la punta de un dedo humano es de unos 26º, con un desplazamiento promedio de unos 10 mm, con una desviación máxima promedio de 21.3 mm.


b. El umbral de discriminación de la dirección de una fuerza aplicada a la punta de un dedo humano no depende de una fuerza de referencia aplicada en una determinada dirección de referencia.

c. En concordancia con las evidencias reportadas en la literatura de la área, sobre la naturaleza anisotrópica de la percepción háptica, parece plausible asegurar que la percepción de la dirección de las fuerzas aplicadas también es anisotrópica, es decir, que no se percibe con igual facilidad la dirección de una fuerza aplicada a un dispositivo háptico en cualquier dirección, por lo que la percepción de la misma también está sujeta a distorsión.

d. La experiencia en el uso y manejo de dispositivos hápticos por parte de sus usuarios representa un factor importante a considerar pues determina un valor del umbral de percepción menor en tanto mayor sea la experiencia del usuario.

e. De acuerdo con investigaciones anteriores, los seres humanos son bastante adeptos a utilizar, en forma natural, información de las fuerzas en el espacio tridimensional durante las tareas de agarre y manipulación típica de objetos. Los aferentes en la palma de la mano proporcionan información abundante y precisa respecto de las componentes de las fuerzas normales y tangenciales que actúan sobre la mano. Específicamente, el aferente SA-I tiende a responder a componentes tangenciales de la fuerza en la dirección distal; el aferente SA-II en la dirección proximal y el tipo FA-I en las direcciones proximal y radial. La naturaleza anisotrópica de las propiedades mecánicas de las puntas de los dedos y la reopuesta neuronal de los receptores mecánicos subyacentes parecen sugerir una distribución anisotrópica de la distribución de los umbrales de discriminación de fuerza-dirección [32] [33].

El entendimiento del funcionamiento de los mecanismos de percepción y

acción de las diferentes partes del cuerpo humano y, en particular, de la mano, requiere, indispensablemente, del conocimiento de los tipos de fibras musculares así como de la manera cómo actúan los nervios que sensan las funciones táctiles (aferentes), y aquellos que controlan los movimientos de la mano (eferentes o efectores); es decir, requiere del conocimiento del Sistema Nervioso Autónomo (SNA) [34].

En el caso de la mano humana, se distinguen dos grandes categorías

de fibras musculares: las de adaptación lenta, referidas más arriba por sus siglas en inglés, SA, por slow-adapting, y aquellas de adaptación rápida, o FA, por las siglas de fast-adapting. Dentro de las fibras de adopción lenta, se distinguen dos tipos, las SA tipo I, o SA-I, y las SA tipo II (SA-II).

También es bien conocido que la percepción del espacio de operación

y trabajo de un brazo manipulador, a veces referido como espacio manipulatorio, [29], es anisotrópico. Por ejemplo, los movimientos radiales


hacia y desde el mismo cuerpo son considerados más largos que los movimientos tangenciales de la misma extensión lineal, [35]. Algunas investigaciones [32] sugieren que está sobreestimación de la extensión lineal desde y hacia el cuerpo se debe a un incremento en el esfuerzo percibido al mover el brazo de uno mismo en esa dirección, de allí que se sugiera que la percepción de la fuerza también dependa de su dirección. Además de la estimación de la distancia, otras investigaciones han examinado la habilidad de la gente para reproducir o igualar ángulos en el espacio manipulatorio. En los estudios llevados a cabo por Chu et alia, [26], se encontraron muchos errores cuando se les solicitó a los participantes a que reprodujeran los ángulos formados por dos localizaciones (sobre un tablero horizontal colocado sobre una mesa en frente de la anterior a través de movimientos guiados; el rango de error varía desde 4,6º hasta 23,3º [29]. En un intento para modelar la percepción háptica en el contexto de planificación y control de la función motora, usando la geometría de Riemann [35][37], como estructura métrica, se encontró que la percepción háptica de longitudes rectangulares y ángulos circunscritos dentro de triángulos también resultaron distorsionados respecto de los valores esperados, pero los resultados no fueron consistentes en que una simple métrica de Riemann no podía explicar simultáneamente las distorsiones en ángulos y longitudes. Al tratar de efectuar la tarea de dibujar un circulo, las distorsiones en ángulos y longitudes resultaron ser consistentes con las distorsiones en su percepción, revelando que existe una relación íntima entre la percepción y la acción en el sistema somatosensorial, [35].

A la luz de todas estas investigaciones, parece apropiado pensar que

la percepción de la de la dirección de una fuerza puede ser también distorsionada. Los umbrales de discriminación de la dirección de la fuerza a lo largo de cinco direcciones diferentes, tres de las cuales están en la dirección de los puntos cardinales, esto es, izquierda (oeste), arriba (Norte), derecha (Este). Esta selección de direcciones permite cubrir el rango de direcciones normales desde los lados frontales superiores de objetos hápticos virtuales desde el punto de vista de un usuario de un dispositivo Phamton. Estas investigaciones han confirmado que las orientaciones vertical y horizontal son más fácil y precisamente percibidas que las orientaciones oblicuas, tanto para la visión como para el tacto; esto es llamado por Chu et alia, como el efecto oblicuo [25], además de los trabajos de Meng y Qian [37]. También se ha sugerido una aparente superioridad proximal-distal en la sensitividad de percepción sobre orientaciones oblicuas y más aún sobre orientaciones mediallateral. No obstante, los estudios de Chu et alia [26], han demostrado la no afectación de la dirección de la fuerza de referencia sobre la precisión con que los humanos pueden discriminar la dirección de otras fuerzas actuantes sobre el mismo dispositivo háptico.


Esta observación, aparentemente contradictoria, debe examinarse desde el punto de vista de los conceptos de precisión (o variabilidad, incertidumbre, resolución, [25,25]). La distorsión es un error sistemático en la magnitud percibida de un estimulo, es decir, es una ilusión, mientras que la variabilidad puede ser medida en términos de umbrales de discriminación. Toda esta evidencia es analizada dentro del contexto del estudio de los, así llamados, propioceptores [39], de importancia indudable en el control de la navegación y de la operación de robots y brazos manipuladores. Los propioceptores son aquellos sensores que forman parte del controlador del robot y usan un modelo de si mismo para monitorear continuamente sus propios efectores, y en ningún caso tratan de modelar ni ―sensar‖ el espacio de trabajo del robot, función ésta que ejercen los externoceptores. La utilización de la Lógica Difusa en el control de navegación y operación de los robots ha sido objeto de estudio por parte de A. Saffiotti y D. Driankov, [38]. En base a todas estas observaciones, es posible que los usuarios de un dispositivo de realimentación de fuerzas puedan percibir fuerzas a lo largo de las direcciones cardinales con más precisión (algo aun no probado), pero su habilidad para discriminar la dirección de fuerzas no depende de la dirección particular de la misma. Obviamente, la definición de direcciones cardinales dependerá directamente de la orientación del cuerpo, configuración de brazo/antebrazo y aun de la inclinación de la cabeza del usuario de un dispositivo de realimentación de fuerza, de acuerdo a las investigaciones de Luyat et alia [39].

Es casi, si acaso absolutamente, imposible establecer un procedimiento de calibración que permita alinear el marco de coordenadas del mundo de una fuerza con los ejes sagital y frontal del cuerpo de un usuario. No obstante, para todos los efectos prácticos de diseño de dispositivos hápticos, resulta muy conveniente el poder asegurar que los umbrales de discriminación de la dirección de una fuerza para usuarios típicos está dentro del rango de 25 a 33º, de acuerdo a los estudios de Chu et alia, [26].

4.3. USO DE LA GEOMETRÍA DE RIEMANN PARA MEDICIÓN DE LA PERCEPCIÓN HÁPTICA.

En vista del interés en el uso de la geometría de Riemann, puestas en boga por Fasse y sus colaboradores [35], a continuación se describe, someramente, la manera en que puede ser utilizada dicha geometría en el estudio de la háptica. Un estudio más formal de esta geometría puede ser consultada en los trabajos del Prof. Sigmundur Gudmundsson [36], de la Universidad de Lund, Suecia.


El desarrollo y evaluación de tecnologías de entornos virtuales hápticos y

de teleoperadores requiere de la medición cuantitativamente objetiva de la calidad háptica. En ese sentido, se han desarrollado varios procedimientos para realizar tal cuantificación de la percepción háptica.

La percepción háptica humana es distorsionada e incierta. La distorsión perceptiva se define como la desviación sistemática de la percepción con respecto a un objetivo estándar. Por otra parte, la incertidumbre perceptiva es definida como la medida de la distribución estadística de lo percibido. Fasse y Hogan, [35], han propuesto una serie de herramientas matemáticas para cuantificar la distorsión y la incertidumbre perceptiva, con lo cual se puede profundizar en la. Investigación de la estructura fundamental de la percepción humana.

A los fines de cuantificar la precisión de la percepción de seres humanos

promedio, Fasse et alia condujeron una serie de experimentos cuyos procedimientos y resultados se publicaron en el año 2000, [35]. Estos investigadores se percataron que la métrica euclideana no sería la más adecuada para la medición de la percepción háptica en seres humanos, debido a la naturaleza anisotrópica de de dicha percepción. Esta característica anisotrópica de obliga a introducir otras consideraciones como la distorsión y la incertidumbre en las mediciones de la percepción háptica.

Es bien sabido que la percepción de objetos en el entorno de un ser

humano está sujeta a múltiples factores que afectan directamente la precisión con la cual tales objetos son percibidos. Es así que la orientación del objeto, así como la orientación de la propia cabeza del sujeto en estudio afecta sensiblemente la percepción de la forma del objeto, de igual manera que afecta la percepción de sus dimensiones. Además, es importante considerar factores tales como la experticia de cada sujeto en particular. Por ejemplo, la percepción del entorno de trabajo de un dispositivo de juegos, como un joystick es notoriamente diferente entre un sujeto familiarizado con el dispositivo y otro totalmente novato en su manejo. La Figura 4.2 muestra la disposición de los sujetos sometidos a los experimentos diseñados por Fasse et alia.


Figura 4.2. Disposición de los sujetos sometidos a estudio, a) para reconocimiento de

longitudes de rectángulos, b) para estimación de amplitud de los ángulos de un triángulo.

En vista de las limitaciones que supone el uso de la métrica euclideana

para los propósitos planteados por Fasse et alia en sus estudios, propusieron la utilización de la geometría de Riemann, una introducción a la misma se puede encontrar en los apuntes del Prof. S. Gudmundsson , [36].

La geometría de Riemann, o rimenniana, permite generar varias métricas

de interés. Así, por ejemplo, Fasse et alia, propusieron experimentos para medir la precisión de la percepción de las dimensiones de objetos rectangulares. Los experimentos consistían en presentar a varios sujetos con los ojos cerrados, con pequeños rectángulos, cuya área no excediera de 5000

2mm . Los sujetos fueron instruidos para que hicieran un reconocimiento, a ojos

cerrados, de las dimensiones xl y yl , haciéndoles palpar el contorno interno de

tales rectángulos. Una vez transcurrido un período de 10 seg., el sujeto debía reportar cuál de las dos dimensiones le había percibido de mayor longitud. La data recolectada fue entonces tabulada y procesada, calculando los cocientes

de yx ll / , para cada rectángulo en particular. Estos cocientes definen la

excentricidad de una elipse, como la que se muestra en la Figura 4.3.

Figura 4.3. Elipse de excentricidad yx ll / .


Para poder dar cierto sentido estadístico a esta data, se calcularon los

logaritmos naturales de cada cociente y se le ajustó una función acumulativa de distribución de probabilidades, la cual resultó ser Gaussiana, con media

aritmética x y desviación estándar .

Las dimensiones xl y yl fueron variadas en un rango tal que 70.0)ln(40.0 yx ll , con incrementos de 007857.0)ln( yx ll . En

términos de la métrica convencional, esto se traduce a yxy lll *13.2*67.0 ,

es decir, que la longitud xl varió desde un 67% de yl hasta algo más del doble

de yl , con incrementos de unas 6 unidades del cociente yx ll / .

Los rectángulos fueron presentados a los sujetos en dos orientaciones

diferentes, una a 0º respecto del plano paralelo al torso de los sujetos y otra a 45º, respecto del mismo plano.

Por ejemplo, para un sujeto dado, los resultados de sus apreciaciones se

ajustaron a una función acumulativa de distribución Gaussiana, con media

aritmética 1856.0x y desviación estándar 0714.0 , para una orientación de

0º. El mismo sujeto presentó una función similar con 0491.0x y 1482.0 , para una orientación de 45º. La gráfica se puede apreciar en la Figura 4.4.

Figura 4.4. Histograma y función de distribución gaussiana de probabilidades ajustada para los resultados de un sólo individuo


Estos resultados permitieron concluir la distorsión perceptiva fue de un significativo 30%. Se observó además que la precisión de lo percibido estaba menos ―disperso‖ en relación a la media para la orientación a 45º, lo cual ratifica lo que se había anticipado en el sentido de que la orientación del objeto puede afectar la precisión de su percepción por parte de un ser humano.

4.4. CONSIDERACIONES DE SOFTWARE RELACIONADO CON DISPOSITIVOS

HÁPTICOS. En la industria de diseño y desarrollo de dispositivos hápticos cada vez

más sofisticados, se ha desarrollado muchas herramientas y ambientes de trabajo en software para elaborar las interfaces de manejo y captación de las características para las cuales se diseñan estos dispositivos.

Para el caso de dispositivos de realimentación de fuerza, como el Phamton utilizado por Chu et al. [26] y E. Vidholm [6], en sus investigaciones, se ha desarrollado el software denominado OpenHaptics, el cual se utiliza conjuntamente con SenseGraphics H3D API. Esta API se construye sobre la caja de herramientas SensAble OpenHaptics para ofrecer una interfaz de scripts, de alto nivel que se puede combinar con el formato estándar X3D para desarrollo de aplicaciones basados en la web. Esto permite desarrollar desde sencillos modelos hasta avanzados simuladores, que utilizan dispositivos hápticos.

4.5. CONCLUSIONES DEL CAPÍTULo.

En la misma dirección de las investigaciones y estudios abordados en este trabajo, muchas líneas de investigación se pueden abrir, por ejemplo, para medir la sensitividad de la gente a percibir variaciones en la dirección del desplazamiento de las puntas de los dedos. Asimismo, para englobar otras facultades del sentido del tacto, con miras a implementación de dispositivos hápticos más realistas, se deben profundizar los estudios en los umbrales de discriminación de otras características físicas de los objetos y superficies, como temperatura, rugosidad, humedad, viscosidad, etc., de manera que los dispositivos hápticos puedan ser utilizados más ampliamente en ambientes naturalmente hostiles, como el manejo de sustancias químicas corrosivas o, de alguna otra manera, peligrosas, muestras de material volcánico, etc.

Por otra parte, los estudios realizados en la área de la Medicina

pudieran y debieran ser utilizados y explotados para obtener mayor complementariedad en el diseño y desarrollo de humanoides. Así, los estudios


de perfusión de la sangre en las puntas de los dedos, vista en la sección 4.2.2., y la detección de otras propiedades de la sangre, pudieran ser de interés científico para el desarrollo de dispositivos hápticos.


5. DESCRIPCIÓN DE LOS LENGUAJES DE PROGRAMACIÓN PARA REALIDAD VIRTUAL.

5.1. INTRODUCCIÓN.

En este capítulo se describen y explican algunos ejemplos de utilización de las primitivas y posibilidades que ofrecen los lenguajes de programación para l construcción de escenas virtuales más populares y que, de hecho, se han establecido como estándares de la industria, avalados ambos por la International Standard Organization (ISO) y por Comisión Internacional Electrotécnica, o IEC (International Electro-technical Commission)

Es importante destacar que X3D asimila todas las prestaciones ofrecidas por VRML. De hecho, los navegadores diseñados para desplegar las escenas creadas en X3D reconocen aquellas escenas creadas bajo VRML, pero agrega una cantidad considerable de posibilidades.

Cabe destacar que, aunque VRML y X3D son los estándares de la industria, reconocidos por la ISO y la IEC, existen otros lenguajes como 3dm e In Tml, sobre los cuales se hacen algunos comentarios, para propósitos de comparación.

5.2. DESCRIPCIÓN DE VRML.

Esta sección está dedicada a la descripción de las funciones primitivas y diferentes nodos que ofrece VRML para el diseño y construcción de escenas virtuales basadas en la web. Más allá del esfuerzo por describir en forma amena y asequible las potencialidades de VRML, la mejor fuente de información técnica referida a esta herramienta se encuentra en sus Especificaciones Técnicas, [12].

Antes de pasar a describir estas dos herramientas, es importante destacar que ambas utilizan como sistema de ejes coordenados globales un sistema tradicional de tres ejes, denominados x, y, z, orientados en las direcciones positivas que se indican en la Figura 5.1.


Figura 5.1. Ejes

5.2.1. Primitivas

En VRML existe una serie de objetos predefinidos que forman el conjunto de primitivas de geometría. Estas primitivas son:

Box (paralelepípedos genéricos: cubos, cajas)

Sphere (esfera)

Cone (cono)

Cylinder (cilindro)

Cada una de estas primitivas es un node.

5.2.2. El nodo Shape

Para poder visualizar estas primitivas, es necesario utilizar el node Shape. Este node tiene dos fields:geometry y appearance.

En el field geometry se especifica la geometría de algún objeto 3D. Es a través de este field que se especifican las primitivas. A continuación se muestra como definir cada una de las primitivas existentes:

Box: Shape {

geometry Box { size 4 3 5 }

}

Figura 5.2. Definición de un nodo Box.

Aquí se define una caja de 4 unidades de ancho, 3 de alto y 5 de fondo (size 4 3 5). Para definir un cubo perfecto de 10 unidades por lado, se debe establecer las tres cifras iguales a 10 (size 10 10 10).

(NOTA: Al visualizar el ejemplo se ve una masa de color gris uniforme debido a que aún no ha definido un material para el objeto.

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#Box

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#Sphere

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#Cone

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#Cylinder

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#Shape

http://www.iua.upf.es/~npares/docencia/vrml/primitiv/box.wrl#_blank


El objeto queda definido de forma que su centro coincide con el origen de coordenadas locales, y que en este caso, como no se han aplicado transformaciones, coincide también con el origen de coordenadas globales o de mundo.

Sphere: Shape {

geometry Sphere { radius 5 }

}

Figura 5.3. Definición de un nodo Sphere.

En la Figura 5.3 se define una esfera de 5 unidades de radio (radius 5). También queda centrada en el origen de coordenadas.

Cone: Shape {

geometry Cone {

bottomRadius 3

height 2

}

}

Figura 5.4. Definición de un nodo Cone.

En la Figura 5.4 se define un cono con una base de 3 unidades de radio (bottomRadius 3) y una altura de 2 unidades (height 2). También queda centrado en el origen de coordenadas.

Cylinder: Shape {

geometry Cylinder {

radius 4

height 5

}

}

Figura 5.5. Definición de un nodo Cylinider.

En la Figura 5.5 se define un cilindro con una base de 4 unidades de radio (radius 4) y una altura de 5 unidades (height 5). También queda centrado en el origen de coordenadas.

http://www.iua.upf.es/~npares/docencia/vrml/primitiv/sphere.wrl#_blank

http://www.iua.upf.es/~npares/docencia/vrml/primitiv/cone.wrl#_blank

http://www.iua.upf.es/~npares/docencia/vrml/primitiv/cylinder.wrl#_blank


5.2.3. Materiales

Para definir la apariencia de las primitivas (y en general de todos los objetos) se debe definir un color o una textura a aplicar a su superficie. A continuación se muestra cómo definir un color dentro de un nodo shape.

Como se ha visto más arriba, el node Shape dispone de un field llamado appearance, que permite definir las características del material del objeto. Para hacerlo se utiliza el node Appearance de VRML.

Este node tiene diversos fields pero se muestra sólo la modificación del field material. Para definir este field se debe utilizar el node Material. Aquí también se explica sólo un field de este node: el field diffuseColor, que hace referencia al color que refleja el objeto, es decir, el color del objeto.

Como se ha mencionado, los colores en VRML se definen en RGB (Red-Green-Blue o Rojo-Verde-Azul). Los valores de R, G y B deben estar dentro del rango [0,1]. Por ejemplo:

Si se quiere definir la caja de antes de

color rojo (RGB = [1,0,0]).

Shape {


appearance Appearance {

material Material {

diffuseColor 1 0 0

}

}

}

Figura 5.6. Ejemplo de definición de la apariencia de un objeto.

Como se puede apreciar, la caja que antes no se distinguía por el hecho de no tener una apariencia asignada que le confiriera características de superficie, ahora se ve claramente y del color rojo que se ha definido.


Otro ejemplo:

Si se quiere definir el cilindro de antes, de color cian

(azul claro) (RGB = [0,1,1]).

Shape {

geometry Cylinder {

radius 4

height 5

}

appearance Appearance {

material Material {

diffuseColor 0 1 1

}

}

}

Figura 5.7. Modificación del color de un objeto.

Muchas características del objeto pueden ser modificadas para mejorar la apariencia y textura de los objetos: color, brillo e iluminación son ejemplos de tales características.

5.2.4. Sensores de Tiempo e Interpoladores.

Los sensores de tiempo son relojes que permiten la sincronización de eventos en las escenas virtudes creadas con VRML. Por otra parte, una muy importante característica que incorpora VRML es el uso de interpoladores, los cuales son herramientas matemáticas que permiten calcular anticipadamente variaciones en posición, iluminación y hasta atenuación de sonido. Estos bloques constructivos permiten la animación de los objetos en la escena.

5.2.4.1. Sensor de Tiempo

En VRML97 se dispone de una herramienta muy potente, el Sensor de Tiempo (TimeSensor). Este es un reloj que se puede utilizar a conveniencia para poder aprovechar el paso del tiempo como motor para mover objetos, cambiar color de objetos, variar orientaciones, etc.

Si se requiere que un objeto gire alrededor de uno de sus ejes conforme va pasando el tiempo, se puede definir que a cada "tic-tac" varíe algún detalle del entorno en construcción, con una cierta frecuencia.

Un TimeSensor se basa en el reloj real de sistema, midiendo el tiempo actual en segundos transcurridos a partir de las 00:00 horas del 1º de Enero del 1970.

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#TimeSensor


A continuación se muestran algunos ejemplos de TimeSensor con efectos distintos:

Se inicia y realiza un ciclo de 5 segundos.

DEF Infinit TimeSensor{

startTime 0

cycleInterval 5

}

Figura 5.8. TimeSensor en VRML

Este TimeSensor se inicia al cargarse el entorno en el visualizador y se para al cabo de 5 segundos. Un TimeSensor da constantemente, como evento de salida (eventOut), la fracción de ciclo que ha transcurrido. Esto lo hace mediante el eventOut SFFloat fraction_changed que es un valor entre 0.0 y 1.0. La duración del ciclo se define en segundos en el exposedField SFTime cycleInterval que en este caso se ha definido a 5 segundos. Es decir, el TimeSensor tardará 5 segundos en pasar el valor de fraction_changed de 0.0 a 1.0. Al haber transcurrido los 5 segundos, y por lo tanto haber llegado a 1.0 el valor de fraction_changed, el TimeSensor dejará de modificar el evento fraction_changed y se parará.

Se inicia y va realizando ciclos de 5 segundos sin pararse.

DEF Infinit TimeSensor{

startTime 0

cycleInterval 5

loop TRUE

}

Figura 5.9. Definición de TimeSensor en VRML.

Ahora, al haber transcurrido los primeros 5 segundos y haber llegado a 1.0 el valor de fraction_changed, como se ha definido que realice bucles con el loop TRUE, el sensor volverá a empezar un nuevo ciclo. Esto lo irá realizando sin pararse hasta que se cargue un entorno nuevo en el visualizador o bien se cierre el visualizador.

Para poder aprovechar el paso del tiempo que proporciona el TimeSensor, se deben utilizar los interpoladores que se explican a continuación.

5.2.4.2. Interpoladores

La interpolación lineal utilizada por VRML97, es una herramienta matemática que permite calcular un punto desconocido que se encuentra localizado entre dos extremos conocidos, asumiendo que la relación de dependencia entre los puntos de todo el intervalo es lineal y que dicho intervalo es continuo.


En VRML97 hay seis tipos de interpoladores:

ColorInterpolator: Interpola colores.

CoordinateInterpolator: Interpola coordenadas de vértices.

NormalInterpolator: Interpola normales a superficies.

OrientationInterpolator: Interpola ángulos de rotación.

PositionInterpolator: Interpola posiciones de objetos.

ScalarInterpolator: Interpola valores cualesquiera (escalares, es decir, univaluados).

A continuación se explica cómo funciona un interpolador de color. Si se quiere que un objeto vaya cambiando de color de forma gradual, empezando por el rojo y terminando en el verde, se debe tener en cuenta que según la forma de definir colores RGB (valores entre 0 y 1) el rojo es el (1 0 0) y el verde es el (0 1 0).

Así pues, se define el interpolador de colores como:

DEF Rojo_a_Verde ColorInterpolator {

key [ 0, 1 ]

keyValue [ 1 0 0, 0 1 0 ]

}

Figura 5.10. Definición de un Interpolador de color.

Con esta definición, se estable que cuando el interpolador empiece (0% del trayecto, key=0) nos dé el color rojo, keyValue=(1 0 0), y cuando termine (100% del trayecto, key=1) el objeto se torne de color verde, keyValue=(0 1 0).

El interpolador deberá ir cambiando el valor de key gradualmente y en función de este valor, ir calculando el valor del color de keyValue. Por ejemplo, cuando sea key=0.5, obtendrá el valor de keyValue=(0.5 0.5 0) que es un tono amarillo medio.

Pero no sólo se puede dar un tramo de interpolación. Se puede establecer que el objeto empiece siendo de color rojo, a continuación pase por verde, después llegue a azul y finalmente vuelva a rojo.

Ahora se tienen tres tramos de cambio de color y por lo tanto

se debe definir el interpolador de colores de la siguiente

forma:

DEF Arcoiris ColorInterpolator {

key [ 0, 0.3, 0.6, 1]

keyValue [ 1 0 0, 0 1 0, 0 0 1, 1 0 0]

}

Figura 5.11. Definición de un Interpolador de Color.

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#ColorInterpolator

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#CoordinateInterpolator

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#NormalInterpolator

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#OrientationInterpolator

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#PositionInterpolator

http://www.iua.upf.es/~npares/docencia/vrml/vrml97def/part1/nodesRef.html#ScalarInterpolator


Aquí se establece que cuando el interpolador empiece (0% del trayecto, key=0) el objeto será de color rojo, keyValue=(1 0 0). Cuando llegue a key=0.3 (aproximadamente un tercio del trayecto) sea de color verde, keyValue=(0 1 0). Al llegar a key=0.6 (aprox. dos tercios) sea de color azul, keyValue=(0 0 1) y, finalmente, cuando termine (100% del trayecto, key=1) se torne dé color rojo nuevamente, keyValue=(1 0 0).

Así, si se ha definido un material aplicado a un objeto, se puede hacer que el interpolador vaya modificando el valor del field Color de este material (ver Materiales) y por lo tanto vaya cambiando el color del objeto al que se le aplica este interpolador. Para ello, se hace un ROUTE desde un evento de salida del interpolador al evento de entrada diffuseColor del material.

Pero, ¿qué es lo que hace que el interpolador vaya pasando del valor inicial al final de forma gradual? Sencillamente, el paso del tiempo de un TimeSensor como los que se han introducido más arriba. Aquí también se tiene que establecer un ROUTE entre el tiempo del TimeSensor y el cambio del valor porcentual del interpolador (es decir, el key).

Las "rutas" que se han visto en secciones anteriores se enlazan a los valores que irán modificando el entorno con los sensores de tiempo y los interpoladores. Esto se puede ver a través de un ejemplo completo de un objeto que va cambiando de color:

Exemple3: Cambiando de color.

DEF motorColor TimeSensor{

loop TRUE

cycleInterval 5

}

DEF Arcoiris ColorInterpolator {

key [ 0, 0.3, 0.6, 1]

keyValue [ 1 0 0, 0 1 0, 0 0 1, 1 0 0]

}

DEF CuboColorCambiante Shape {


appearance Appearance { material DEF materialColorCambiante

Material {} }

}

ROUTE motorColor.fraction_changed TO Arcoiris.set_fraction

ROUTE Arcoiris.value_changed TO materialColorCambiante.diffuseColor

Figura 5.12. Cambiando el color.

http://www.iua.upf.es/~npares/docencia/vrml/interpol/colorint.wrl#_blank


Seguidamente se analiza qué hace este segmento de código:

En primer lugar se define un TimeSensor al que se ha denominado motorColor. Este TimeSensor se pondrá en marcha al cargar el entorno e irá actuando en ciclos de 5 segundos sin pararse nunca.

A continuación, se define un ColorInterpolator de tres tramos (rojo-verde, verde-azul, azul-rojo) de la misma longitud, aproximadamente un tercio cada uno.

En tercer lugar, se define un objeto, el CuboColorCambiante, que como su nombre indica, es un cubo que va cambiando de color. Este objeto se define como una geometría que es una caja (Box) que forma un cubo, y por una apariencia con un material. Al material se le ha asignado el nombre materialColorCambiante pero no tiene ningún parámetro definido: Material { }. Esto se debe a que el campo diffuseColor será tratado como evento de entrada (eventIn).

Finalmente, se establecen las rutas:

o La primera define que el paso del tiempo del TimeSensor vaya

haciendo avanzar el trayecto recorrido por el interpolador de color. Esto se logra enlazando el evento de salida fraction_changed del TimeSensor motorColor con el evento de entrada set_fraction del ColorInterpolator Arcoiris. Con este enlace, cada "tic-tac" del TimeSensor hace incrementar en una pequeña porción el avance del ColorInterpolator.

o La segunda enlaza el nuevo color generado por el ColorInterpolator después de haber avanzado (debido a la acción del TimeSensor) con el color del objeto. Esto se consigue enlazando el evento de salida, eventOut value_changed, del ColorInterpolator con el evento de entrada, eventIn diffuseColor, del material materialColorCambiante del cubo que se ha definido.

o

Del mismo modo en que se vinculó un TimeSensor a un ColorInterpolator, se puede hacer para cualquier otro interpolador.

5.3. DESCRIPCIÓN DE X3D.

Esta sección está dedicada a la descripción de las funciones primitivas y diferentes nodos que ofrece X3D para el diseño y construcción de escenas virtuales basadas en la web. Más allá del esfuerzo por describir en forma amena y asequible las potencialidades de VRML, la mejor fuente de información técnica referida a esta herramienta se encuentra en sus Especificaciones Técnicas, [14].


5.3.1. Plataforma de Operación de X3D.

Una de las versiones más recientes y probadas de X3D es la denominada M10, que se puede obtener desde http://www.xj3d.org/download.html.

Para poder ser utilizada, se requiere tener instalada la versión 1.4.2. del lenguaje de programación Java, la cual permite utilizar la implementación de Xj3D, es decir, la herramienta de software que permite interactuar con el mundo virtual a través de Java. Una versión de Java más reciente que ha demostrado ser igualmente funcional es la 1.6.0_05, utilizada por el autor de este trabajo.

Esta posibilidad de utiliza Java es quizás la característica más poderosa de X3D, pues, como es sabido, Java puede ser ejecutado casi en cualquier plataforma de hardware comercialmente disponible, lo cual permite que los mundos virtuales diseñados bajo Xj3D puedan ser accedidos desde cualquier punto de acceso a Internet.

Además de Java, la plataforma de hardware sobre la cual se trabaja debe disponer, al menos, de la compilación 1.6.0_05-b13 de Java SE Runtime Environment.

Así mismo, X3D requiere de una máquina virtual, para ―emitir‖ y ―escuchar‖ mensajes a.C. y desde el mundo virtual. Se puede utilizar la compilación 10.0-b19 mixed mode, sharing> de Java NetSpot Client VM. Todos estos productos se distribuyen en forma libre por su fabricante Sun Microsystems, Inc.

El paquete completo de X3D se puede obtener ejecutando: java –jar Xj3D-M10-RC2-platform.jar

Existe suficiente documentación sobre X3D en el sitio de Internet: http://www.xj3d.org/javadoc/index.html

Ademas, el Web 3D Consortium, que agrupa a distintos equipos de trabajo en áreas relacionadas con la robótica, Internet y el diseño y construcción de escanarios de Realidad Virtual, ha elaborado una especificaciones y ejemplos, que están disponibles en: www.web3d.org. Una vez instalado el paquete de X3D, es necesario contar con unos visualizadores y plug-ins, dependientes del ambiente operativo sobre el cual se trabaja, para poder explotar las potencialeidades del mismo y sus herramietnas afines. Algunos de esots viewers y plug-ins son:

http://www.xj3d.org/download.html


– Para Windows • Octagon Free Player: www.octaga.com • BS Contact VRML 6.1: www.bitmanagement.de • OpenWorlds: www.openworlds.com • Flux v.1.1.: www.mediamachines.com

– Para Linux • FreeWrl: freewrl.sourceforge.net

5.3.2. ¿Cómo hacer que Xj3D acepte código Java?

Primero que todo, para hacer que Xj3D acepte el byte code de Java, la clase debe implementar la interfaz org.web3d.x3d.sai.X3dSriptImplementation, y debe ser declarada como ―public‖. Como dice la documentación javadoc, hay varios métodos que deben ser implementados pero sólo uno es realmente importante:

public void setField(X3DScriptNode externalView,

java.util.Map campos)

Figura 5.13. Declaración de un SetField como público

donde 'campos' aplicará una cadena sobre un objeto, con el nombre de cada uno de los campos, correspondientemente aplicados a sus respectivos valores dentro de la clase. Estas clases son implementadas con X3DField. 5.3.3. Descripción de la herramienta X3D. En esta sección se describe la arquitectura de X3D, así como sus componentes e interrelaciones. La Figura 5.14 muestra esquemáticamente su arquitectura.


Figura 5.14. Arquitectura de X3D.

Figura 5.15. Relación de X3D con XML.


El scene graph es la estructura fundamental del ambiente run-time de X3D. Esta estructura contiene todos los objetos del sistema y sus relaciones. Los objetos pueden ser:

Primitiva geométrica

Materiales

Fuentes luminosas

Puntos de vista

Sensores

Fuentes de audio

El scene graph es un grafo acíclico orientado (DAG – direct acyclic graph) en

el que los nodos pueden contener campos constituidos por nodos-hijos , como se muestra en la Figura 5.16

Figura 5.16. Estructura interna de un Scene Graph.

Al interior de los scene graph se puede individualizar una jerarquía de las

transformaciones (transformation hierarchy) que incluye todos los nodos raíz y sus descendientes así como su colocación en el espacio 3D.

En base a la transformation hierarchy:

• Los nodos raíz están posicionados respecto del sistema de coordenadas globales (world) de la escena

• Los nodos hijos están posicionados respecto a un sistema de coordenadas locales (local) definido en términos de transformaciones a partir del sistema de coordenadas del nodo padre

• Toda escena X3D define implicitamente un sistema de coordenadas globales, como se muestra en la Figura 5.17.


Figura 5.17. Sistemas de Coordenadas.

Al interrior del scene graph se puede tener conexiones (routes) entre campos de nodos distintos: estas conexiones constituyen el behaviour graph

Figura 5.18. Conexiones entre nodos. Behaviour Graph .

El grafo de comportamiento (behaviour graph ) posee dos características importantes:

especifica cómo los eventos se propagan en el sistema

es modificable dinámicamente reindexando (rerouting), adicionando o suprimiendo conexiones

Ejemplo de routing de los eventos: al trascurrir el tiempo (desde 0 a 5 segundos), el cono se moverá desde la posición A hasta la posición B


Figura 5.19. Ejemplo de routing de eventos.

El ambiente run-time de X3D: • visualiza la escena (rendering) • recibe entrada desde diversas fuentes (sensores) y coordina la elaboración de

los eventos • gestiona el estado corriente del scene graph • gestiona las relaciones entre el browser X3D y las aplicaciones externas por el

hyperlinking y el acceso a través de API • gestiona el ciclo de vida de los objetos individuales (sean objetos incorporados

(built-in) o sean definidos por el usuario)

El sistema X3D está constituido por un conjunto de entidades abstratas

llamadas objetos

5.3.3.1. Nodos (nodes)

Los nodos son instancias declaradas en un fichero o usando código procedimental a tiempo de ejecución

El programador puede crear nuevos tipos de nodos a través del mecanismo de

prototyping. De esta manera se puede convertir parte del ambiente run-time. Los nuevos tipos de nodos vienen a ser tratados como objetos propios de X3D (built-in).

Por otra parte, la mayor parte de los tipos de nodos implementan la funcionalidad

aditiva, a través de la herencia de la interfaz (propiedad y funcionalidad comunes), propia de la Programación Orientada a Objetos.


Cada nodo contiene cero o más campos que definen:

• el estado persistente del nodo • los valores que el nodo puede emitir y recibir bajo la forma de eventos

Los nodos son derivados de los objetos X3Dnode, los cuales representan los

conceptos más complejos dentro del entorno de X3D, y pueden contener uno o más fields para memorizar los datos internos o para emitir o recibir los eventos

Algunos objetos como las declaraciones ROUTE, PROTO, metadata, e

informaciones sobre Components y Profiles, no son campos en los nodos Los nodos están constituidos por campos, los cuales no son más que

variables declaradas de algún tipo de datos abstractos.


5.3.3.2. Campos (Fields)

Los campos son derivados del objeto X3DField y representan las entidades

abstractas más simples dentro de X3D. Por ejemplo: valores booleanos, cadenas de caracteres, array de valores en coma flotante .

Un campo puede contener: • un valor singular de un tipo de dato (SF...) • un array de valores del mismo tipo (MF...) Los campos pueden ser declarados de acuerdo a los tipos de datos listados

en la Figura 5.20.

SFBool, MFBool

SFColor, MFColor

SFColorRGBA, MFColorRGBA

SFDouble, MFDouble

SFFloat, MFFloat

SFInt32, MFInt32

SFImage, MFImage

SFNode, MFNode

SFRotation, MFRotation

SFString, MFString

SFTime, MFTime

SFVec2d, MFVec2d

SFVec2f, MFVec2f

SFVec3d, MFVec3d

SFVec3f, MFVec3f

TRUE / FALSE

(R G B) componentes (0,1)

(R G B A) componentes (0,1)

floating-point en doble precisión

floating-point en simple precisión

entero de 32-bit

imagen 2D no comprimida:

longitud, altura, n° componentes

longitud x altura, en pixeles

nodo X3D

(x y z a): rotación de a radianes

respecto al eje (x y z)

cadena codificada en UTF-8

valor en doble precisión: segundos a

partir del 1° enero 1970, 00:00:00

vector bidimensional de double

vector bidimensional de float

vector tridimensional de double

vector tridimensional de float

Figura 5.20. Tipos de datos definidos en X3D:

5.3.3.1.1. Tipos de Acceso a los Campos.

Existen 4 tipos de acceso a los campos de un nodo, los cuales van a determinar de qué manera puede ser modificado o no su contenido. Estos son:

• initializeOnly: no recibe ni emite eventos • inputOnly: solamente permite la recepción de eventos • outputOnly: solamente permite la recepción de eventos • inputOutput: permite tanto la recepción como la emisión de eventos


5.3.3.1.2. Reglas para la asignación de nombres a los campos.

• Todos los nombres compuestos por más de una palabra comienza con una

minúscula, mientras que las sucesivas iniciales son mayúsculas – Ejemplo: nombreCompuestoDeVariasPalabras

• Los campos inputOnly tienen el prefijo “set_” – Ejemplo: set_foo – Excepciones: addChildren, removeChildren, algunos campos del tipo

„SFTime‟ • Los campos outputOnly tienen el sufijo “_changed”

– Ejemplo: foo_changed – Excepiónes: los campos de tipo SFBool (ex: isActive), algunos campos

del tipo „SFTime‟ • Los campos inputOutput agregan al propio nombre el prefijo “set_” o el sufijo

“_changed” según sea usada en la recepción o en el envio de eventos – Ejemplo: foo, set_foo, foo_changed

Figura 5.21. Estructura de un nodo.

5.3.3.2. Eventos.

Un evento es el medio primario para generar los comportamientos en el ambiente run-time. Los eventos en la salida están conectados a los eventos a la entrada in modo declarativo.

Para poder establecer una conexión (ROUTE) entre dos campos, es preciso

asociar un nombre a los nodos. Estos nombres pueden ser construidos con DEF / USE.

Los eventos son generados por sensores o scripts y pueden propagarse a lo

largo del behaviour graph. Una cascada de eventos está caracterízada por el mismo timestamp

5.3.3.3. Relaciones: Transformation hierachy

La relaciones se definen a través de las transformaciones, las cuales a su vez se organizan en una jerarquía, conocida como Transformation hierarchy, en la


terminologís de X3D. Estas transformaciones escriben las relaciones espaciales entre los objetos a visualizar.

Además, las relaciones permiten establecer el grado de comportamiento o

Behaviour graph, el cual describe las conexiones entre los campos de los objetos y el flujo de los eventos a través del sistema.5.3.4. Conceptos y Componentes de X3D. En esta sección se explican los conceptos y componentes fundamentales de X3D. Como se verá más adelante, existen componentes primitivas que se definen y manejan de igual forma que en VRML97. 5.3.4.1. Conceptos Importantes.

Una Componente de X3D es un onjunto de objetos X3D y servicios que proveen la funcionalidad entre sus relacionados.

– Ej: Rendering component, Sound component, Scripting component –

Una componente especifica uno o más niveles de calidad de servicios

Un Perfil es un conjunto de funcionalidades y requisitos que deben ser soportados a fin de que una implementación sea conforme a tal perfil.

– Ej: Core profile, Interactive profile, Full profile

Los perfiles se definen como un conjunto de componentes y de los

correspondientes niveles. La Figura 5.22 muestra una posible composición de un perfil.

Figura 5.22. Perfil.


5.3.4.2. Estructura Abstracta de X3D.

Los ficheros que contienen la descripción de una escena virtual elaborada en X3D, está conformada por diferentes secciones que conforman su estructura:

– Un Header o encabezamiento, que es una claúsula declarativa que

depende de la codificación utilizada. Un Header permite la • Identificación del estándar soportado (―X3D‖) • Identificación del sistema de codificación de ios caracteres

(“UTF-8”) – Declaración del perfil. – Declaración de los componentes adicionales (opcional) – Declaración de los metadata (opcional). La metadata es de carácter

informativo que • no modifica el scene graph. y • sirve para especificar informaciones adicionales.

- Declaraciones para la creación y la organización de los nodos en el scene graph

Figura 5.23. Estructura de un fichero X3D.


X3D hace uso del lenguaje de marcación conocido como XML, para establecer sus relaciones con el entorno de la red Internet.

Figura 5.23. Lenguaje de mark-up (XML).

Figura 5.24. Estructura de un fichero X3D/XML.

• Todos los tag deben estar encerrados en un tag raíz

5.3.4.3. Algunos Comentarios sobre la Sintáxix de XML. En vista de la relación directa entre X3D y XML, es necesario observar rigurosamente el respeto de la sintáxis común a estos lenguajes, A continuación, se hacen algunos comentaiors pertinenetes. Tags. Los tags son marcadores que se utilizan para identificar clarametne el inicio y el fin de cada estructura definida dentro el programa. • Todos los tags deben cerrarse:

– Tag de apertura y de cierre: <tag>...</tag> – Tag vacio: <tag/>

• los tag disinguen minúsculas de mayúsculas (case sensitive), es decir, – <myTag> y <MYTAG> no son equivalentes

• los valores de los atributos deben estar encerrados entre comillas dobles – <myTag height=―5‖ description=―BlaBlaBla‖>

• los tag deben estar correctamente anidados entre si – Correcto: <firstTag><secondTag>...</secondTag></firstTag> – Incorrecto: <firstTag><secondTag>...</firstTag></secondTag>

Caracteres especiales Los caracteres especiales permitidos en X3D/XML se listan a continuación:

– & & – < < – > > – ‗ ' – ― " –

Comentarios de documentación.

Los comentarios van comprendidos entre los tag  – <!– Esto es un comentario -->

CDATA

Los CDATA no son más que pedazos de texto que se pueden incoproar a lo largo de todo el cuerpo del programa y cuyo contenido no es analizado por el interpretador de XML. Los CDATA van comprendidos entre los tag <![CDATA[ y ]]>, como se muestra en el siguiente ejemplo:

<![CDATA[

Texto no analizado por el parser ―XML‖ ]]>


Transformaciones (Transform)

Los nodod Transform permiten implementar cambios sobre los objetos dentro de la escena. Estos cambios pueden ser de posición, de dolor, de apariencia, etc.

Figura 5.25. Nodo Transform (1).

• Transform: crea un sistema de coordenadas local para operar las

transformaciones geométricas • Shape: crea una forma compuesta de un objeto geométrico y de un aspecto • Cylinder: una de las diversas primitivas geométricas • Material: definición de la propiedad de la superficie

Figura 5.26. Nodo Transform (2).

La transformación que se muestra en las Figuras 2-25 a 2-27 realiza

varias acciones, a saber:

– Define un sistema de coordenadas local para los nodos contenidos en children

– Efectúa una transformación geométrica de: – Un redimensionamiento (aunque no-uniforme) respecto a un punto

arbitrario – Una rotación respecto a un eje y a un punto arbitrario – Una traslación


Figura 5.27. Nodo Transform (3)

Reglas generales dentro de un nodo Transform:

• Los campos de tipo SFNode o MFNode están comprendidos entre el tag de apertura y el de cierre

• Todos los otros campos son definidos como atributos del tag • Los atributos DEF y USE nos permite atribuir un nombre al nodo e

instanciarlo (replicarlo) sucesivamente

Figura 5.28. Ejemplo

A continuación, las Figuras 5.29 a 5.31 muetran la sintáxis y estructura de los

nodos Shape, Appearance y Material.


Figura 5.29. Nodo Shape

Figura 5.30. Nodo Appearance


Figura 5.31. Nodo Material (1)

Figura 5.32. Nodo Material (2)


5.3.4.4. Primitivas Geométricas de X3D. Seguidamente se muestran las primitivas geométricas de X3D, como son la Caja (Box), el cilindro (cylinder), la esfera (sphere) y el cono (cone), las cuales son esencialmente iguales a las de VRML.

Figura 5.33. Primitivas Geométricas (1).

Figura 5.34. Primitivas Geométricas (2).

Todos los nodos descendientes de X3DGeometryNode tienen un campo solid (SFBool). El tipo de acceso definido para estos campos es InitializeOnly.


5.3.4.4.1. Nodo NavigationInfo

El nodo NavigationInfo describe cuál paradigma de navegación habilitar. Los

paradigmas de navegación disponivles son: – Walk – Examine – Fly – ...

Además, el nodo NavigationInfo permite realizar las siguietnes acciones:

– describe las características físicas del avatar – especifiac las dimensiones del avatar anotación de colisiones – habilita o deshabilita una fuente luminosa direccional orientada en la

dirección de observación – establece límites de visibilidad

El nodo NavigationInfo se deriva de X3DbindableNode. Sólo puede estar activo un objeto de ese tipo dentro de una escena X3D. La Fiura 2-35 muestra un ejemplo de definición de este tipo de nodos.

Figura 5.35. Ejemplo de definición de NavigationInfo

Otros Ejemplos

– <NavigationInfo type=„“WALK” “FLY”‟/> – <NavigationInfo type=“NONE” headlight=“false”/> – <NavigationInfo type=“EXAMINE” avatarSize=“0.3 1.8 0.8”/>


5.3.4.4.2. Nodo ViewPoint Un nodo ViewPoint permite definir los puntos de vista, en términos de:

– Posición respecto del sistema de coordenadas del nodo padre – Direccion de la mirada

Además, permite asociar a un punto de vista una descripción:

A través del Menú de puntos de vista en el browser X3D se puede: • Definir la amplitud del campo visual • Definir un centro de rotación para el modo EXAMINE

El nodo ViewPoint deriva de X3DbindableNode. Puede estar activo sólo un objeto de este tipo dentro de una escena X3D.

Figura 5.36. Ejemplo de definición de ViewPoint

Otros Ejemplos – <Viewpoint description= ―Del'alto‖

position=―0 10 0‖ orientation=―1 0 0 1.57‖/> – < Viewpoint description= ―Grandangulo‖ fieldOfView=―1.3‖/>

El punto de vista es definido a través de los atributos:

– Position: posición en el sistema de coordenadas local – Orientation: rotación del vector ―dirección de observación‖, inicialmente

orientado a lo largo del eje –z


– Para establecer en modo más simple un punto de vista es aconsejable recurrir

a las transformaciones geométricas –

– Figura 5.37. Nodo ViewPoint (3)

El nodo Transform TargetPoint representa el punto observado del Viewpoint.

Retrasando y rotando TargetPoint, es posible modificar la dirección de observación, la cual apuntará siempre al centro del sistema de coordenadas de ―TargetPoint‖

Figura 5.38. Varios ejemplos de ViewPoints.

5.3.4.4.3. Iluminación. Una muy importante característica a la hora de diseñar y construir una escena virtual la iluminación. En X3D, están definidas tres tipos de fuentes de luz. Éstas son:

– DirectionalLight: rayos paralelos generados por una fuente luminosa en el inifinito

– PointLight: fuente luminosa puntiforme, atenuación – SpotLight: fuente luminosa puntiforme (―faro‖), atenuación


Figura 5.39. Iluminación (1)

Figura 5.40. Iluminación (2)

5.3.4.4.4. Anchor

• Permite crear los link activamente haciendo clic sobre sus objetos hijos: – Link a ficheros distribuidos sobre la red y a viewpoint de la escena X3D

• url = ―fileName‖ • url = ―fileName.x3d#viewpointName‖ • url = ―#viewpointName‖

• Permite especificar los parámetros al Browser – “keyword=value” (ex: “target = name_of_frame”)


Figura 5.41. Definición de un Anchor.

5.3.4.4.5. Temporizadores (Timers)

– Sensores que generan eventos al pasar el tiempo

Figura 5.42. Definición de un TimeSensor.

–

5.3.4.4.6. Interpoladores

– Interpolación lineal entre: • Posiciones • Rotaciones • Colores • Escalares

Figura 5.43. Interpoladores.

• ...


– Definimos un conjunto de valores clave (posiciones, colores, ...) asociados a valores comprendidos en el intervalo [0,1]

Figura 5.44. Interpoladores.

5.3.4.4.7. Enrutamiento de Eventos. ROUTER

• El tag <ROUTE .../> permite conectar dos campos de dos nodos distintos después de describir el behaviour graph

• Sintáxis: <ROUTE fromField=―...‖ fromNode=―...‖ toField=―...‖ toNode=―...‖/>

• los campos fromNode y toNode contienen los nombres de los dos nodos – por consiguiente, esos deben ser nombrados a través del atributo DEF

Los campos especificados en los atributos fromField y toField deben ser del

mismo tipo. • el campo especificado en el atributo fromField debe ser

– bien de tipo outputOnly, – o bien de tipo inputOutput

• el campo especificado en el atributo toField debe ser – Bien de tipo inputOnly, – o bien de tipo inputOutput


5.3.4.4.8. Animación de la traslación de un nodo transform

Figura 5.45. Animación de Transform.

Ejemplo.

Animación de la rotación de un paralelepípedo, del color de una esfera y de la traslación de un cono

a. Creación de tres objeto distribuidos a lo largo del eje X

Figura 5.46. Creación de tres objetos.

b. Creación de un TimeSensor

Figura 5.47. Creación de un TimeSensor.


c. Creación de 3 interpoladores

Figura 5.48. Creación de tres interpoladores.

d. Enrutamiento (routing) de los eventos

Figura 5.49. Ejemplo de enrutamiento de los eventos.

5.3.4.5. Otros Sensores: Visibilidad, Proximidad y de Audio.

En esta sección se describen los sensores de proximidad (ProximitySensor) y de Visibilidad (VisibilitySensor), así como el nodo de sonido (Sound), los cuales son muy útiles en la elaboración de animaciones de escenarios virtuales. 5.3.4.5.1. Sensor de proximidad (ProximitySensor)

El sensor de proximidad tiene dos funciones principales, a saber:

• Detecta cuando el avatar entra (y se encuentra) en una zona representada por un paralilepípedo

• Cuando el usuario se encuentra en el interior del paralilepípedo, el sensor traza su posición y orientación

ProximitySensor : X3DEnvironmentalSensorNode { SFBool [in,out] enabled TRUE SFVec3f [in,out] center 0 0 0 SFVec3f [in,out] size 0 0 0 SFTime [out] enterTime SFTime [out] exitTime SFRotation [out] orientation_changed SFVec3f [out] position_changed SFBool [out] isActive

... }

Figura 5.50. Creación de un ProximitySensor.


En la definición de un sensor de proximidad se especifica:

1. Una variable lógica que permite habilitar /deshabilitar el sensor 2. Un vector de 3 componentes de tipo coma flotante, simple precisión, que

contiene las coordenadas del centro del paralelepípedo. 3. Un vector de 3 componentes de tipo coma flotante, simple precisión, que

contiene las especificaciones de tamaño del paralelepípedo. 4. Dos variables de tipo SFTime, que guardan automáticamente la hora de

entrada y de salida del avatar de la zona delimitada por el paralelepípedo. 5. Además, el sensor de proximidad genera dos eventos, a saber:

orientation_changed y position_changed, que pueden ser utilizados para hacerle seguimiento al avatar dentro del paralelepípedo.

6. Una variable lógica, que indica si el avatar está activo dentro de la área.

Con ayuda de un sensor de proximidad, se puede:

iniciar (o terminar) las animaciones cuando el avatar se avecina a (o aleja de)

un objeto particular mover un objeto de manera que replique el movimiento del avatar (útil para la

creación de interfaces) 5.3.4.5.2. Animación de un paralelepípedo en base a la cercanía del avatar A continuación se muestra el flujo de los eventos que ocurren cuando un avatar se acerca a un determinado sensor de proximidad. En primer lugar, Cuando el sensor de proximidad detecta la cercanía del avatar, se pueden activar varias sensores de tiempo que permiten hacerle seguimiento dentro del paralelepípedo previamente definido. Seguidamente, los interpoladores de posición calcula las nuevas posiciones del avatar y de los objetos dentro de la escena que se quieran afectar como consecuencia de la cercanía del avatar. Opcionalmente, se pueden definir transformaciones de tamaño, apariencia, brillo, etc., que se deseen aplicar sobre los objetos movidos dentro de la escena.


Figura 5.51. Ejemplo de animación.

5.3.4.5.3. Posicionamiento de un objeto en base a la posición del avatar. Para modificar la posición de los objetos que pertencen a una escena virtual creada con X3D, como consecuencia del cambio de posición de un avatar, el sensor de proximidad permite al programdor especificar la nueva orientación (orientation_changed) y las coordenadas de la nueva posición (position_changed). La nueva orientación y posición de cada objeto que se desee afectar, son pasadas a las transformaciones adecuadas para modificar el sistema de coordenadas locales del avatar. Es importante destacar que el detector de colisiones debe estar desactivado para que el navegador no evite el movimiento de los objetos dentro de la escena.


Figura 5.52. Posicionamiento de un objeto.

5.3.4.5.4. Sensor de Visibilidad (VisibilitySensor)

Los sensores de visibilidad detectan cuándo un área representada por un

paralelepípedo es visible al avatar.

VisibilitySensor : X3DEnvironmentalSensorNode { SFBool [in,out] enabled TRUE SFVec3f [in,out] center 0 0 0 SFVec3f [in,out] size 0 0 0 SFTime [out] enterTime SFTime [out] exitTime ... }

Figura 5.53. Definición de un VisibilitySensor

En la definición de un sensor de visibilidad se especifica:

1. Una variable lógica que permite habitar/deshabilitar el sensor 2. Un vector de 3 componentes de tipo coma flotante, simple precisión, que

contiene las coordenadas del centro del paralelepípedo. 3. Un vector de 3 componentes de tipo coma flotante, simple precisión, que

contiene las especificaciones de tamaño del paralelepípedo. 4. Dos variables de tipo SFTime, que guardan automáticamente la hora de

inicio y de terminación de que la zona delimitada por el paralelepípedo de nuestro interés sea visible para el avatar.

Los sensores de visibilidad permiten iniciar (o terminar) las animaciones apenas el avatar pueda ver un objeto en particular ubicado dentro de una determinada zona de la escena virtual, lo cual los hace útiles para llamar la atención de un usuario activo en la escena.


5.3.4.5.5. El Nodo de Sonido (Sound).

Para darle más realismo a una animación, se la puede incorporar música o efectos de sonido. Para esto, la herramienta X3D ofrece el nodo Sound, el cual se define como se muestra a continuación:

Sound : X3DSoundNode { SFVec3f [in,out] location 0 0 0 SFVec3f [in,out] direction 0 0 1 SFFloat [in,out] intensity 1.0 SFFloat [in,out] minFront 0 SFFloat [in,out] minBack 0 SFFloat [in,out] maxFront 0 SFFloat [in,out] maxBack 0 SFNode [in,out] source NULL [X3DSoundSourceNode] SFBool [] spatialize TRUE ...

} Figura 5.54. Definición de un nodo de audio.

En la definición de un nodo de sonido se especifica:

1. Un vector de 3 componentes de tipo coma flotante, simple precisión, que contiene las coordenadas de la ubicación de la fuente de sonido.

2. Un vector de 3 componentes de tipo coma flotante, simple precisión, que contiene su dirección en la escena virtual.

3. Dos variables de tipo coma flotante, que contienen la distancia mínima (minFront) y máxima (maxFront) hacia delante de la fuente de sonido hasta donde se quiere que se escuche el sonido.

4. Dos variables de tipo coma flotante, que contienen la distancia mínima (minBack) y máxima (maxBack) hacia atrás de la fuente de sonido hasta donde se quiere que se escuche el sonido. (ver modelo acústico).

Figura 5.55. Puntos de interés para definir un nodo de audio.


5.3.4.5.6. AudioClip Se puede incorporar cualquier fichero de audio, en formato: .wav, .midi o .mp3), para lo cual de define un nodo como el que se especifica a continuación:

AudioClip : X3DSoundSourceNode { SFBool [in,out] loop TRUE SFFloat [in,out] pitch 1 SFTime [in,out] startTime 0 SFTime [in,out] stopTime 0 SFTime [in,out] pauseTime 0 SFTime [in,out] resumeTime 0 MFString [in,out] url ―‖ SFTime [out] duration_changed SFTime [out] elapsedTime SFBool [out] isActive SFBool [out] isPaused ... }

Figura 5.56. Definición de un AudioClip.

En la definición de un nodo X3DSoundSourceNode se especifica:

1. Una variable lógica que debe estar en TRUE para que se escuche el sonido proveniente de la fuente de sonido.

2. Una variable de tipo coma flotante, simple precisión, que establece el tono y/o velocidad (pitch) del sonido.

3. Dos variables de tipo SFTime, que especifican la hora de inicio y de finalización de la reproducción del sonido.

4. Dos variables de tipo SFTime, que especifican la hora de inicio de una pausa y la hora de reinicio de la reproducción del sonido.

5. Una variable tipo MFString permite especificar la dirección del sitio (url) desde donde se leerá el fichero de audio que se desea reproducir.

6. Este nodo genera dos eventos de salida, a saber: duration_changed, que indica la culminación del tiempo establecido para la reproducción del sonido, y elapsedTime, que acumula el tiempo transcurrido desde el inicio de la reproducción.

7. Dos variables lógicas, que permiten saber si el nodo está activo y si está parado temporalmente (pausa).


5.4. OTROS LENGUAJES DE REALIDAD VIRTUAL. Además de VRML y X3D, existe una variedad de lenguajes de programación y algunas plataformas de desarrollo que se han propuesto como herramientas para la construcción de escenas virtuales en la web. Entre estos lenguajes está 3dml, a cuyo lugar en Internet se puede acceder a través de http://www.cs.ualberta.ca/~pfiguero/3dml/.

Por otra parte, se ha propuesto la plataforma de integración conocida como InTml, Interaction Techniques Markup Language. Esta arquitectura se puede implementar sobre otras cajas de herramientas, con el fin de facilitar el rápido desarrollo de prototipos de aplicaciones de Realidad Virtual, permitiendo el desarrollo en C++ y Java, y pueden ser ejecutadas en varias plataformas de hardware. 5.5. EJEMPLO DE APLICACIÓN DE VRM/EAI. Como ejemplo de aplicación de la plataforma de construcción de escenarios virtuales basados en la web, conjuntamente con la interfaz EAI, la Figura 5.57 muestra un robot diseñado y desarrollado por M. Röhrmeier [17][18]. Nótese que, además de los controles de navegación propias del navegador que se utilice (Parallel Graphics Cortona browser u Octagon Player), la interfaz EAI permite incorporar controles específicos diseñados por el creador de la escena. Muchos otros ejemplos, de aplicación pueden ser encontrados en páginas de INTERNET, dentro de las que destacan las proporcionadas por el equipo de trabajo del NIST (National Institute of Standards and Technology), [20].

http://www.cs.ualberta.ca/~pfiguero/3dml/


Figura 5.57. Robot basado en la web, desarrollado en VRML/EAI

Tomado de [18].

5.6. CONCLUSIONES DEL CAPÍTULO.

Los lenguajes de programación de escenarios virtuales deben contemplar un manejo fácil de crear las escenas y los objetos que la confomran, además de una cantidad de factores que permiten darle mayor visosidad, naturalidad, etc., como por ejemplo, iluminación, brillo, color, constraste, entre otros. En este setnido, VRML y X3D ofrecen una cantidad de herramientas y nodos predefinos, los cuales sólo deben ser parametrizados dando valores a ciertas variables, com altura, díametro, inclinación , etc. De la facilidad que ofrezcan estos lenguajes para los usuarios no necesariamente expertos en progrmacación, depende la mayor o menor difusión y popularidad que pueda gozar un determinado lenguaje. En este sentido, VRML y X3D han alcanzado bastante aceptación y se han establecido como estándares del mercado. No ocurre así con otros lenguajes como 3dml e InTml, que ofrecen una variedad de funcones para la construcción de gráficos.


No obstante, el autor considera que estos lenguajes, a pesar de lo que proclaman sus promotores, requieren de un conocimiento bastante sólido de programación orientada a objetos, por lo que es preferible el uso de VRML o X3D, pues ofrecen una plataforma de más alto nivel para la construcción de entornos virtuales. Además, como ya se ha mencionado, VRML y X3D son estándares reconocidos por la ISO.


Página Intencionalmente dejada en blanco


6.

CONCLUSIONES.

El presente trabajo permitió la realización de una revisión amplia de tópicos de interés relacionados son la Telerrobótica y la Teleoperación. Se ha pretendido obtener así un conocimiento base del esado del arte de estas dos importantes disciplinas de la tecnología de software y hardware.

A continuación se destacan algunas observaciones resaltantes sobre los

resultados de este estudio, tratando de indicar los aspectos más relevantes de cada capítulo.

En el Capítulo 2, se han descrito a través de ejemplos, áreas de aplicación de la

Telerrobótica y de la Teleoperación, las que han incluido desde la medicina hasta la inspección geológica. Los ejemplos de aplicación en el área médica contemplados aquí, comprenden la visualización y el análisis de imágenes tomadas por equipos de Resonancia Magnética y de Tomografía por Computadora. Especial mención se hace en la Sección 2.3.1. de la Tomografía Óptica Coherente, la cual ha representado un importante adelanto en el diagnóstico y tratamiento de enfermedades del ojo humano.

Por otra parte, los ejemplos de aplicación en la inspección geológica

comprenden la utilización de robots teleoperados, como el Marskhod, visto en la sección 2.4.1. Todas estas investigaciones entrañan un interés especial para cada una de las especialidades que han hecho uso de la Telerrobótica y de la Teleoperación, pero subyace un interés primordial, y que consiste en la obtención de más y más información no sólo de nuestro entorno en la Tierra, sino también, y de manera muy importante, de los entornos de otros planetas, cometas y satélites naturales cercanos al nuestro. En tanto mayor sea el conocimiento que podamos obtener de tales cuerpos siderales, tanto mejor podría ser el aprovechamiento de los recursos que ellos poseen. Así, nuevos materiales podrían desarrollarse a partir de elementos y que no existen en nuestro planeta.

La posibilidad de realizar experimentos en entornos espaciales, extraterrestres,

ofrece toda una variedad de expectativas, sin dejar de mencionar la continuidad de la búsqueda de evidencias de otras formas de vida allende los límites de nuestro planeta.

El muy importante campo de la Medicina no deja de ser una de las áreas más

favorecidas con este tipo de investigaciones. La exploración del fondo de nuestros


océanos, mediante el uso de vehículos teleoperados, continuamente arroja nuevas formas de atacar enfermedades humanas que, hasta ahora, no tenían cura. Así mismo, tales exploraciones han permitido descubrir la quimiosíntesis, la cual consiste en la obtención de nutrientes a partir de sustancias químicas provenientes de fuentes de aguas termales submarinas. En contraposición a la creencia generalmente aceptada hasta ahora, en el sentido de que la fotosíntesis era el único mecanismo de subsistencia de las especies vegetales, se ha comprobado que la quimiosíntesis sustenta formas de vidas, hasta ahora, insospechadas, que pueden subsistir a temperaturas y condiciones increíbles, en completa ausencia de luz.

Las áreas de entretenimiento, la enseñanza y aprendizaje, y hasta la ergonomía, tampoco escapan de ser susceptible de beneficiarse con nuevos desarrollos de aplicaciones, a partir de la utilización de la Telerrobótica y de la Teleoperación.

En el Capítulo 3 se han revisado algunas maneras de describir matemáticamente la cinemática, tanto directa como inversa, de un robot móvil. La relación entre descripciones matemáticas, lenguajes de programación gráfica (VRML en la Sección 3.2 y X3D en la Sección 3.3.) y representación de humanoides en escenas virtuales viene dada por que, desde el punto de vista mecánico, el soporte del cuerpo humano lo constituye un conjunto de articulaciones y vínculos (huesos) que conforman el esqueleto. Estos vínculos y articulaciones se deben representar matemáticamente para efectos de reproducir sus movimientos dentro de un ordenador. Una vez que se tiene la representación matemática, ésta debe ser convertida en un código que pueda ser interpretado por el ordenador, el cual, además, deberá mostrar gráficamente las diferentes posiciones que deba asumir el humanoide, de acuerdo a los cálculos derivados del modelo matemático. Por último, la apariencia humana de este humanoide se la da el conocimiento y utilización de las medidas y proporciones de los seres humanos, aportadas por documentos como el ISO-7250, el cual a su vez se basó en el proyecto CAESAR.

Aunque los jacobianos, revisados en la Sección 3.4.1.1., ofrecen una descripción muy completa de toda la cinemática, su utilización involucra cálculos pesados y susceptibles a errores de aproximación y redondeo que pueden derivar en errores considerables en la representación y naturalidad de los movimientos de los robots. Por esta razón, aparte de otras de carácter más intuitivo, se sugiere la utilización del método de representación Denavit-Hartenberg, revisado en la Sección 3.4.1.2.. Igualmente, se revisaron dos lenguajes de programación utilizados en la representación gráfica de los robots en escenas virtuales. Estos son VRML y X3D. En vista de que X3D reconoce el formato de archivos de VRML y, además, incropora otros elementos que enriquecen la escena y los objetos que aparecen en ella, se sugiere la utilización de éste como herramienta para la construcción de escenas virtuales basadas en la web.


Al final del capítulo se incluyen detalles de la representación de humanoides en escenas virtuales. Esta representación está basada en las medidas y proporciones del cuerpo humano compiladas en el documento ISO-7250 [21], las cuales están basadas en los resultados del proyecto CAESAR [19].

En la misma dirección de las investigaciones y estudios abordados en este trabajo, muchas líneas de investigación se pueden abrir, por ejemplo, para medir la sensibilidad de la gente a percibir variaciones en la dirección del desplazamiento de las puntas de los dedos. Asimismo, para englobar otras facultades del sentido del tacto, con miras a implementación de dispositivos hápticos más realistas, se deben profundizar los estudios en los umbrales de discriminación de otras características físicas de los objetos y superficies, como temperatura, rugosidad, humedad, viscosidad, etc., de manera que los dispositivos hápticos puedan ser utilizados más ampliamente en ambientes naturalmente hostiles, como el manejo de sustancias químicas corrosivas o, de alguna otra manera, peligrosas, muestras de material volcánico, etc.

Por otra parte, los estudios realizados en la área de la Medicina pudieran y

debieran ser utilizados y explotados para obtener mayor complementariedad en el diseño y desarrollo de humanoides. Así, los estudios de perfusión de la sangre en las puntas de los dedos, vista en la sección 4.2.2., y la detección de otras propiedades de la sangre, pudieran ser de interés científico para el desarrollo de dispositivos hápticos.

En vista de la necesidad de codificar todas estas mediciones y características

de los robots así como del entorno en donde operan, se requiere de lenguajes de programación adecuados, los cuales no sólo permitan la realziación de cálculos a gran velocidad sino que también ofrezcan posibilidades gráficas, para mostrar en tiempo real los resultados de aquellos cálculos. Por esta razón, y en complemento a lo que se trató en el Capítulo 3, el Capítulo 5 contiene detalles esepcíficos de las primitivas y la sintaxis de VRML [12][13] y X3D [15][16]

Los lenguajes de programación de escenarios virtuales deben contemplar un manejo fácil de crear las escenas y los objetos que la conforman, además de una cantidad de factores que permiten darle mayor viscosidad, naturalidad, etc., como por ejemplo, iluminación, brillo, color, contraste, entre otros. En este sentido, VRML, revisado en las secciones 3.2 y 5.2, y X3D, tratado en las secciones 3.3 y 5.3, ofrecen una cantidad de herramientas y nodos predefinidos, los cuales sólo deben ser parametrizados dando valores a ciertas variables, como altura, diámetro, inclinación , etc. No obstante, la construcción punto a punto de formas irregulares está disponible a través del GeometryNode. De la facilidad necesariamente expertos en programación, depende la mayor o menor difusión y que ofrezcan estos lenguajes para los usuarios no popularidad que pueda gozar un determinado lenguaje. En este sentido, VRML y X3D han


alcanzado bastante aceptación y se han establecido como estándares del mercado. No ocurre así con otros lenguajes como 3dml e InTml, revisados en la sección 5.4., que ofrecen una variedad de funciones para la construcción de gráficos. No obstante, el autor considera que estos lenguajes, a pesar de lo que proclaman sus promotores, requieren de un conocimiento bastante sólido de programación orientada a objetos, por lo que es preferible el uso de VRML o X3D, pues ofrecen una plataforma de más alto nivel para la construcción de entornos virtuales. Además, como ya se ha mencionado, VRML y X3D son estándares reconocidos por la ISO [13][14][16].


REFERENCIAS.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

Diccionario de la Telerrobótica, disponible en la dirección de Internet: http://www.thefreedictionary.com/telerobotics. Visitado el 12 de Noviembre del 2007.

Lang, S., Naef, M., Gross, M., Hovestadt, L. IN:SHOP - Using Telepresence and Immersive VR for a New Shopping Experience. http://blue-c.ethz.ch/publications/inshop.pdf. Stern, Ch., Noser, H., Weissmann, J. y Stucki, P.. Eurographics Workshop on Virtual Environments: Application Scenarios for Scientific Visualization and Virtual Reality Using a CAVE Infrastructure. Deisinger, J. & Kunz, A. (Editors). The Eurographics Association 2003.

Iradier, M. Cirugía Refractiva. LASIK. Website: http://www.drairadier.com/cirugia/crefractiva.htm, Consultado 30 de Marzo del 2008. Sitio de Tecnología de la Información de la Universidad de Iowa. http://myweb.uiowa.edu/jni/visualization/visualization.html. Visitado el 13 de Enero del 2008. Vidholm, E. Visualization and haptics for interactive medical image analysis. ISSN 1651- Disponible en: http://publications.uu.se/abstract.xsql?dbid=8409. Universidad de Uppsala, Suecia, Marzo, 2008.

The New York Eye and Ear Infirmary. Optical Imaging Center. http://www.nyee.edu/optical-coherence-tomography-clinical-database.html

Wettergreen, D. et al., Field Experiments with the Ames Marsokhod Rover.

Disponible en el siguiente sitio de Internet: http://citeseerx.ist.psu.edu/viewdoc/ summary?doi=10.1.1.41.1926.

Wettergreen, D., Thomas, H.; Bualat, M. Inspection Robots Visual Control Navigation Geology Sampling. IEEE International Conference on Intelligent Robots and Systems; Grenoble, France. Sep. 1997

Campbell. B. y McCandless, W. Introduction to Space Sciences and Spacecraft Applications. Gula Publishing Company. Houston, Texas, EE.UU. 1996.

Elbert, B. The Satellite Communication Applications Handbook. Artech

http://www.thefreedictionary.com/telerobotics

http://blue-c.ethz.ch/publications/inshop.pdf

http://blue-c.ethz.ch/publications/inshop.pdf

http://www.drairadier.com/cirugia/crefractiva.htm

http://myweb.uiowa.edu/jni/visualization/visualization.html


[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

House, Inc. Boston, MA. EE.UU. 2004.

Web3D Consortium - VRML97 and Related Specifications - Part 1 (ISO/IEC 14772-1). Disponible en: www.web3d.org/x3d/specifications/vrml Fernández-Lozano, J. Using VRML as a telerobotic man-machine interface. Working Paper. European Space Agency. Noordwijk. Holanda. Agosto, 1999. ISO-9126-1 Software Engineering Technical Specifications. Disponible en: www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm

Extensible 3D (X3D), ISO/IEC 19775-1:2004, Part 1 -- 7 Core componentX3D. Disponible en: http://www.web3d.org/x3d/specifications/ ISO-IEC-19775-X3DAbstractSpecification/ Extensible 3D (X3D), ISO/IEC 19775-2:2004 -- Part 2: Index page. Part 2: Scene access interface (SAI). ISO/IEC 19775-2:2004. Disponible en: www.web3d.org/x3d/specifications/ISO-IEC-19775-2 Röhrmeier, M. Mobiles, kletterfähiges Robotersystem für automatisierte Handhabungsaufgaben in der Fertigung. Disponible en: http://deposit.ddb.de/cgi-bin/dokserv?idn=96284702x&dok_var=d1 &dok_ext=pdf &filename=96284702x.pdf Röhrmeier, M. Web-Based Robot Simulation Using Vrml. Proceedings of the 2000 Winter Simulation Conference J. A. Joines, R. R. Barton, K. Kang, and P. A. Fishwick, eds. Disponible en: http://www.informs-cs.org/wsc00papers/210.PDF

CAESAR web site: http://www.sae.org/technicalcommittees/caesumm.htm

www.itl.nist.gov/iaui/ovrt/projects/vrml/h-anim/surfaceLandmarks.html

ISO 7250-1:2008 - Basic human body measurements for technological ISO 7250-1:2008 provides a description of anthropometric measurements which can be used as a basis for comparison of population groups. ... www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=4415

http://www.emedicine.com/

http://www.therhinoplastycenter.com/Rhinoplasty-Manual/ch1_1.html

http://www.web3d.org/x3d/specifications/

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=4415

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=4415

http://www.therhinoplastycenter.com/Rhinoplasty-Manual/ch1_1.html


[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

Specifications ISO-IEC-19774-HumanoidAnimation/HAnim/FeaturePoints.html Chu, L. User Performance and Haptic Design Issues for a Force-Feedback Sound Editing Interface. Center for Computer Research in Music and Acoustics, Stanford University held by the author/owner(s). CHI 2002, April 20-25, 2002, Minneapolis, Minnesota, USA.

Mascaro, S. y Asada, H.H. The Common Patterns of Blood Perfusion in the Fingernail Bed Subject to Fingertip Touch Force and Finger Posture. Vol. 4, No. 3, 21-July-2006.

Goodwin, A. W., Macefield, V. G. y Bisley, J. W. Encoding of Object Curvature by Tactile Afferents From Human Fingers. Consultado el 30 Mayo del 2008. Disponible en: http://jn.physiology.org/cgi/content/full/78/6/2881 Birznieks, I., Jenmalm, P., Goodwin, A. W., & Johnson, R. S., Encoding of direction of fingertip forces by human tactile afferents. The Journal of Neuroscience, 21, 8222-8237, 2001. Wheat, H. E., Salo, L. M., & Goodwin, A. W., Human ability to scale and discriminate forces typical of those occurring during grasp and manipulation. The Journal of Neuroscience, 24, 3394-3401, 2004.

Hughes, B. Haptic Exploration and the Perception of Texture Orientations, Vol. 4, No. 2, 21-Apr-2006 Haptics-e, Vol. 4, No. 2, Disponible en: http://www.haptics-e.org

Tan, H.Z., Barbagli, F., Salisbury, K., Ho, C. y Spence, C. Force-Direction Discrimination is Not Influenced by Reference Force Direction. Vol. 4, No. 1, 3-Feb-2006

Barbagli, F., Salisbury, K., Ho, C., Spence, C., & Tan, H. Z., Haptic discrimination of force direction and the influence of visual information. ACM Transactions on Applied Perception, 3, 2006.

Mountcastle, V.B. The Sensory Hand: Neural Mechanisms of Somatic Sensation, Harvard University Press. 2005.

Armstrong, L., & Marks, L. E., Haptic perception of linear extent. Perception & Psychophysics, 61, 1211-1226, 1999.

Fasse, E.D., Hogan, N., Kay, B.A. y Mussa-Ivaldi, F.A. Haptic interaction with virtual objects. Spatial perception and motor control. Biology and


[36]

[37]

[38]

[39]

Cybernetics. Vol. 82, pp. 69-83, USA, 2000.

Gudmundsson, S. An Introduction to Riemannian Geometry (version 1.260 - 1 June 2008) Lund University, Suecia. Disponible en: http: www.maths.lth.se/matematiklu/personal/sigma/

Meng, Xin y Qian, N. The oblique effect depends on perceived, rather than physical, orientation and direction. Disponible en: http://brahms.cpmc.columbia.edu/publications/oblique2.pdf. //ºwww.matematik.lu.se/matematiklu/personal/sigma/index.html

Driankov, D. y Saffiotti, A. Fuzzy Logic Techniques for Autonomous Vehicle Navigation: A Reminder on Fuzzy Logic. Springer-Physica Verlag, DE, 2001. Pages 25-47. Luyat, M., Gentaz, E., Corte, T. R., & Guerraz, M. Reference frames and haptic perception of orientation: Body and head tilt effects on the oblique effect. Perception & Psychophysics, 63, 541-554, 2001.

interfaces para aplicaciones de · interfaces para aplicaciones de mero. ... virtual basada en la...

Documents