Diseño de una aplicación didáctica para la monitorización ...DISEÑO DE UNA APLICACIÓN PARA LA...

Francisco Ochoa Bueno

Diseño de una aplicación didáctica para la monitorizacióny simulación del robot STAÜBLI RX-60

Carlos Elvira Izurrategui

Proyecto Fin de Carrera

Ingeniería Eléctrica

2012-2013

Título

Autor/es

Director/es

Facultad

Titulación

Departamento

PROYECTO FIN DE CARRERA

Curso Académico

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2013

publicaciones.unirioja.esE-mail: [email protected]

Diseño de una aplicación didáctica para la monitorización y simulación del robot STAÜBLI RX-60, proyecto fin de carrera

de Francisco Ochoa Bueno , dirigido por Carlos Elvira Izurrategui (publicado por laUniversidad de La Rioja), se difunde bajo una Licencia

Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los

titulares del copyright.

DISEÑO DE UNA APLICACIÓN PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60

UNIVERSIDAD DE LA RIOJA

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INDUSTRIAL


“DISEÑO DE UNA APLICACIÓN DIDÁCTICA PARA LA

MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60”

DIRECTOR: CARLOS ELVIRA IZURRATEGUI

AUTOR: FRANCISO OCHOA BUENO

TITULACIÓN: I.T.I. ELECTRÓNICA INDUSTRIAL

FECHA: 31 de Enero de 2013


Enero 2013 Ingeniería Técnica Industrial Electrónica - Universidad de La Rioja


I

Resumen

El presente proyecto trata de facilitar el aprendizaje de elementos básicos de la robótica

a través de una aplicación informática. Consiste, por tanto, en la creación de un software

didáctico para adquirir conocimientos básicos sobre robótica, tanto en forma de simulación

como interactuando con un robot real, en este caso un brazo robot Staübli RX-60.

Para poder alcanzar esta meta, antes se realiza un repaso a las principales librerías

gráficas 3D y simuladores de robótica existentes en la actualidad. Por un lado, el estudio de

las librerías gráficas aporta conocimientos sobre la forma de crear entornos virtuales de

simulación y la forma de trabajar con ellos, permitiendo seleccionar para el desarrollo de la

aplicación en cuestión aquel que ofrezca unas características más interesantes y acordes al

proyecto. Por otro lado, un repaso de otros softwares de robótica similares proporciona

información sobre cómo están diseñadas las interfaces de usuario y sobre qué funcionalidades

se pueden ofrecer al usuario.

Debido a los conocimientos técnicos del autor, la elección de la plataforma de trabajo es

Windows y el lenguaje de programación elegido es C++, que además es un lenguaje que se

ejecuta rápido, lo cual es importante a la hora de conectar la aplicación con el controlador real

del robot para monitorizar su posición. La comunicación se realiza a través del puerto serie

RS232.



II

Palabras Clave

Robot

Cinemática

Cadena cinemática

Conexión serie RS232

Interfaz de usuario

Librería gráfica 3D

Simulación




1

DOCUMENTO 1.

ÍNDICE GENERAL

“DISEÑO DE UNA APLICACIÓN DIDÁCTICA PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL

ROBOT STAÜBLI RX-60”







2

0. ÍNDICE GENERAL

DOCUMENTO 1. .................................................................................... ÍNDICE GENERAL 1

0. ÍNDICE GENERAL ........................................................................................................................................ 2

DOCUMENTO 2. .................................................................................................. MEMORIA 7

1. ÍNDICES DE MEMORIA ............................................................................................................................... 9

1.1 ÍNDICE DE CONTENIDO ........................................................................................................................... 9

2. OBJETO ......................................................................................................................................................... 11

3. ALCANCE...................................................................................................................................................... 12

4. ANTECEDENTES ......................................................................................................................................... 15

5. NORMAS Y REFERENCIAS ...................................................................................................................... 16

5.1 DISPOSICIONES LEGALES Y NORMAS APLICADAS .................................................................................. 16 5.2 BIBLIOGRAFÍA ...................................................................................................................................... 16

5.2.1 Libros o documentos ............................................................................................................................ 16 5.2.2 Páginas web ......................................................................................................................................... 16

5.3 PROGRAMAS DE CÁLCULO .................................................................................................................... 17

6. DEFINICIONES Y ABREVIATURAS ....................................................................................................... 18

6.1 DEFINICIONES ....................................................................................................................................... 18 6.2 ABREVIATURAS .................................................................................................................................... 18

7. REQUISITOS DE DISEÑO .......................................................................................................................... 19

8. ANÁLISIS DE SOLUCIONES ..................................................................................................................... 20

8.1 LENGUAJE DE PROGRAMACIÓN ............................................................................................................. 20 8.1.1 Alternativas analizadas........................................................................................................................ 20 8.1.2 Solución adoptada ............................................................................................................................... 21

8.2 COMPILADOR ........................................................................................................................................ 22 8.2.1 Soluciones estudiadas .......................................................................................................................... 22 8.2.2 Solución adoptada ............................................................................................................................... 23

8.3 TIPO DE CONEXIÓN ............................................................................................................................... 23 8.3.1 Soluciones estudiadas .......................................................................................................................... 23 8.3.2 Solución adoptada ............................................................................................................................... 23

8.4 DISEÑO DE LA INTERFAZ DE USUARIO .................................................................................................. 24 8.5 LIBRERÍA GRÁFICA 3D .......................................................................................................................... 24

8.5.1 Listado de librerías gráficas analizadas .............................................................................................. 24 8.5.2 Tabla comparativa ............................................................................................................................... 25 8.5.3 Solución adoptada ............................................................................................................................... 26

8.6 ELEMENTOS Y FUNCIONALIDADES DE LAS APLICACIONES DE ROBÓTICA .............................................. 26

9. RESULTADOS FINALES ............................................................................................................................ 27

9.1 INTRODUCCIÓN ..................................................................................................................................... 27 9.2 ARQUITECTURA GENERAL DEL SISTEMA ............................................................................................... 27 9.3 ELEMENTOS DEL SISTEMA ..................................................................................................................... 29

9.3.1 Resumen de componentes empleados .................................................................................................. 29 9.3.2 Componentes hardware ....................................................................................................................... 29



3

9.4 CONTROLADOR CS7 DEL BRAZO ROBOT ............................................................................................... 35 9.4.1 Protocolo de comunicación V+ ........................................................................................................... 36

9.5 LIBRERÍAS DE DESARROLLO ESPECÍFICAS ............................................................................................. 38 9.5.1 Librería de interfaz de usuario Qt ....................................................................................................... 38 9.5.2 Librería QExtSerialPort para el manejo del puerto serie ................................................................... 39 9.5.3 Librería gráfica 3D OpenSceneGraph ................................................................................................ 40

9.6 FASES DE DESARROLLO......................................................................................................................... 41 9.6.1 Introducción ......................................................................................................................................... 41 9.6.2 Fase del modelo matemático ............................................................................................................... 41 9.6.3 Fase de la escena virtual ..................................................................................................................... 49 9.6.4 Fase de interfaz de usuario .................................................................................................................. 51 9.6.5 Fase de comunicaciones RS-232 ......................................................................................................... 57

9.7 POSIBLES MEJORAS O AMPLIACIONES FUTURAS .................................................................................... 60

10. PLANIFICACIÓN DEL PROYECTO ........................................................................................................ 61

DOCUMENTO 3. ...................................................................................................... ANEXOS 63

0. ÍNDICE DE ANEXOS ................................................................................................................................... 65

1. ANEXO I – ESTUDIO DE LIBRERÍAS GRÁFICAS EXISTENTES EN EL MERCADO ................... 66

1.1 CONCEPTOS GENERALES DE LAS LIBRERÍAS GRÁFICAS 3D .................................................................... 66 1.1.1 Conceptos de librerías gráficas ........................................................................................................... 66

1.2 LIBRERÍAS GRÁFICAS DE BAJO NIVEL EXISTENTES EN EL MERCADO PARA LOS DISTINTOS SISTEMAS

OPERATIVOS ....................................................................................................................................................... 71 1.2.1 Direct3D .............................................................................................................................................. 71 1.2.2 OpenGL (+OpenGL Shading Language, +OpenGL ES) ..................................................................... 73 1.2.3 VRML y X3D ........................................................................................................................................ 77 1.2.4 WebGL ................................................................................................................................................. 81

1.3 LIBRERÍAS GRÁFICAS DE ALTO NIVEL EXISTENTES EN EL MERCADO PARA LOS DISTINTOS SISTEMAS

OPERATIVOS ....................................................................................................................................................... 83 1.3.1 Java 3D ................................................................................................................................................ 83 1.3.2 Ogre ..................................................................................................................................................... 86 1.3.3 OpenGL Performer .............................................................................................................................. 90 1.3.4 Open Inventor ...................................................................................................................................... 92 1.3.5 OpenSG ................................................................................................................................................ 95 1.3.6 OpenSceneGraph ................................................................................................................................. 97

2. ANEXO II- LIBRERÍAS PARA EL DESARROLLO DE LA INTERFAZ DE USUARIO ................. 102

2.1.1 Fast Light Toolkit (FLTK) ................................................................................................................. 102 2.1.2 GTK+ (Gimp Toolkit) ........................................................................................................................ 103 2.1.3 Qt 104 2.1.4 wxWidgets .......................................................................................................................................... 106

3. ANEXO III – ANÁLISIS DE APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN

COMERCIALES Y GRATUITAS EXISTENTES ........................................................................................ 108

3.1 APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN COMERCIALES EXISTENTES ............................... 108 3.1.1 ABB RobotStudio ............................................................................................................................... 108 3.1.2 FANUC Robotic’s ROBOGUIDE ...................................................................................................... 110 3.1.3 KUKA Sim Pro ................................................................................................................................... 113 3.1.4 Microsoft Robotics Studio (MRS) ...................................................................................................... 114

3.2 APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN EDUCATIVAS EXISTENTES .................................. 117 3.2.1 RoboAnalyzer ..................................................................................................................................... 117



4

3.2.2 RoboUALab ....................................................................................................................................... 117

4. ANEXO IV – CÓDIGO DE LA APLICACIÓN ....................................................................................... 118

DOCUMENTO 4. ....................................................................................................... PLANOS 203

0. ÍNDICE DE PLANOS ................................................................................................................................. 204

DOCUMENTO 5. PLIEGO DE CONDICIONES ...................................................................................... 206

1. ÍNDICE DEL PLIEGO DE CONDICIONES ........................................................................................... 207

2. ESPECIFICACIONES DE MATERIALES Y ELEMENTOS CONSTITUTIVOS DEL OBJETO DEL

PROYECTO ...................................................................................................................................................... 209

2.1 LISTADO DE MATERIALES EMPLEADOS ............................................................................................... 209 2.1.1 Hardware ........................................................................................................................................... 209 2.1.2 Software ............................................................................................................................................. 209

2.2 REQUISITOS ........................................................................................................................................ 209 2.2.1 Requisitos de hardware ..................................................................................................................... 209 2.2.2 Requisitos de software ....................................................................................................................... 209

DOCUMENTO 6. ..................................................................... ESTADO DE MEDICIONES 211

0. ÍNDICE DEL ESTADO DE MEDICIONES ............................................................................................. 213

1. LISTADO DE PARTIDAS DE OBRA ....................................................................................................... 214

1.1 DESARROLLO DEL SOFTWARE DE MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60 ....... 214 1.1.1 Cuadro de precios 1.1.1 (software) ................................................................................................... 214 1.1.2 Cuadro de precios 1.1.2 (horas de trabajo) ....................................................................................... 214

1.2 COMPONENTES HARDWARE ................................................................................................................ 215 1.2.1 Cuadro de precios 1.2.1 ..................................................................................................................... 215

DOCUMENTO 7. .......................................................................................... PRESUPUESTO 216

0 ÍNDICE DEL PRESUPUESTO .................................................................................................................. 217

1 PRESUPUESTO .......................................................................................................................................... 218

1.1 DESARROLLO DEL SOFTWARE DE MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60 ....... 218 1.1.1 Presupuesto 1.1.1 (software) ............................................................................................................. 218 1.1.2 Presupuesto 1.1.2 (horas de trabajo) ................................................................................................ 218

1.2 COMPONENTES HARDWARE ................................................................................................................ 219 1.2.1 Presupuesto 2.1.1 ............................................................................................................................... 219

2. RESUMEN DEL PRESUPUESTO ............................................................................................................ 220

MEMORIA DISEÑO DE UNA APLICACIÓN PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60



5

1. Í ndice de Figuras

Figura 1 Brazo robot Staübli RX-60 .................................................................................................................. 19 Tabla 1 Comparación de distintas librerías 3D ................................................................................................ 25 Figura 2 Arquitectura general del sistema utilizado en el proyecto ................................................................ 28 Figura 3 Partes del robot Staübli RX-60 ........................................................................................................... 30 Figura 4 Equivalencias entre brazo humano y brazo robot ............................................................................ 31 Figura 5 Dimensiones del robot Staübli RX-60 (en mm) ................................................................................. 32 Tabla 2 Límites de amplitud, velocidad y resolución ....................................................................................... 33 Figura 6 Brazo robot Staübli RX-60 instalado en la UR .................................................................................. 33 Figura 7 Volumen de trabajo del brazo robot .................................................................................................. 34 Tabla 3 Capacidad de carga ............................................................................................................................... 35 Tabla 4 Inercia de las articulaciones 5 y 6 ......................................................................................................... 35 Figura 8 Detalle de las articulaciones extremas del robot................................................................................ 35 Figura 9 Aspecto del Controlador CS7 .............................................................................................................. 36 Tabla 5 Configuración de parámetros del puerto serie .................................................................................... 37 Tabla 6 Resumen de comandos utilizados ......................................................................................................... 38 Figura 10 Qt Designer ......................................................................................................................................... 39 Figura 11 Aplicación ejecutándose y mostrando la visualización con OpenSceneGrpah ............................. 40 Figura 12 Descripción de la posición ................................................................................................................. 41 Figura 13 Descripción de posición + orientación .............................................................................................. 42 Tabla 7 Composición de rotaciones. Primero 0 a 1, después 1 a 2 .................................................................. 42 Figura 14 Composición de rotaciones en orientación tipo Roll-Pitch-Yaw .................................................... 43 Figura 15 Partes de un robot PUMA ................................................................................................................. 45 Figura 16 Sistema de coordenadas de elementos y sus parámetros ................................................................ 45 Figura 17 Pasos en la selección de los marcos de referencia para D-H ........................................................... 47 Tabla 8 Parámetros DH del robot Staübli RX-60 ............................................................................................. 48 Figura 18Posición de ángulos nulos ................................................................................................................... 48 Figura 19 Programa PolyTrans 3D mostrando el eslabón 2 del robot ........................................................... 49 Figura 20 Posibilidad de mostrar cuatro visores .............................................................................................. 51 Figura 21Aspecto de la aplicación ...................................................................................................................... 52 Figura 22 A la derecha panel de cinemática directa ......................................................................................... 53 Figura 23 Diversas configuraciones del robot ................................................................................................... 54 Figura 24 Panel de la versión inicial de cinemática directa a la derecha abajo y en medio la cinemática

directa .......................................................................................................................................................... 54 Figura 25 Panel de cinemática inversa a la derecha ......................................................................................... 55 Figura 26 Línea de envío por el puerto serie ..................................................................................................... 55 Figura 27 Ventana para enviar programas ....................................................................................................... 56 Figura 28 Panel de puerto serie equivalente en la versión ampliada .............................................................. 56 Figura 29 Conectores serie RS-232 (a la izquierda de 25 pines y a la derecha de 9) ..................................... 58 Tabla 9 Funcionalidad de pines del puerto serie .............................................................................................. 58 Figura 30 Conectores serie ................................................................................................................................. 59 Tabla 10Pasos en la planificación del proyecto ................................................................................................. 61 Figura 31Diagrama de Gantt del proyecto ........................................................................................................ 62 Figura 32Pipeline general en gráficos 3D .......................................................................................................... 69 Figura 33. Capa de abstracción simplificada de Direct3D ............................................................................... 72 Figura 34 Versión simplificada del pipeline de OpenGL ................................................................................. 74 Figura 35 Capa de abstracción simplificada en OpenGL ................................................................................ 75




6

Figura 36 Ejemplo de aplicación X3D ejecutándose en un navegador ........................................................... 77 Figura 37 Ejemplo de mismo código en VRML y en X3D ............................................................................... 79 Figura 38 Acuario virtual en WebGL ................................................................................................................ 82 Figura 39 Laboratorio virtual de robótica RoboUALab diseñado en Java 3D .............................................. 84 Figura 40 Ejemplo realizado con la librería OGRE ......................................................................................... 86 Figura 41 Ejemplo de quirófano renderizado en OpenGL Performer ........................................................... 91 Figura 42 Aplicación en Open Inventor de SGI ............................................................................................... 93 Figura 43 VSG Open Inventor utilizado en una aplicación de Michelin ........................................................ 94 Figura 44 Aplicación creada con OpenSG que permite visualizar un tumor cerebral en renderizado

volumétrico obtenido a partir de una tomografía computerizada ......................................................... 96 Figura 45 Laboratorio virtual EOR utilizando en universidades de Moscú .................................................. 98 Figura 46 Ejemplo de interfaz en FLTK ......................................................................................................... 103 Figura 47 Ejemplo de interfaz en GTK+ ......................................................................................................... 104 Figura 48 ............................................................................................................................................................ 105 Figura 49 Software ABB RobotStudio ............................................................................................................. 109 Figura 50 SoftwareFANUC RoboGuide .......................................................................................................... 111 Figura 51 ............................................................................................................................................................ 113 Figura 52 ............................................................................................................................................................ 115 Tabla 11 Cuafro precios software .................................................................................................................... 214 Tabla 12 Cuadro de precios horas trabajadas ................................................................................................ 215 Tabla 13 Cuadro de precios hardware ............................................................................................................ 215 Tabla 14 Presupuesto software ......................................................................................................................... 218 Tabla 15 Presupuesto horas trabajadas .......................................................................................................... 219 Tabla 16 Presupuesto hardware ....................................................................................................................... 219

2. Í ndice de Tablas

Tabla 1 Comparación de distintas librerías 3D ................................................................................................ 25 Tabla 2 Límites de amplitud, velocidad y resolución ....................................................................................... 33 Tabla 3 Capacidad de carga ............................................................................................................................... 35 Tabla 4 Inercia de las articulaciones 5 y 6 ......................................................................................................... 35 Tabla 5 Configuración de parámetros del puerto serie .................................................................................... 37 Tabla 6 Resumen de comandos utilizados ......................................................................................................... 38 Tabla 7 Composición de rotaciones. Primero 0 a 1, después 1 a 2 .................................................................. 42 Tabla 8 Parámetros DH del robot Staübli RX-60 ............................................................................................. 48 Tabla 9 Funcionalidad de pines del puerto serie .............................................................................................. 58 Tabla 10Pasos en la planificación del proyecto ................................................................................................. 61 Tabla 11 Cuafro precios software .................................................................................................................... 214 Tabla 12 Cuadro de precios horas trabajadas ................................................................................................ 215 Tabla 13 Cuadro de precios hardware ............................................................................................................ 215 Tabla 14 Presupuesto software ......................................................................................................................... 218 Tabla 15 Presupuesto horas trabajadas .......................................................................................................... 219 Tabla 16 Presupuesto hardware ....................................................................................................................... 219




7

DOCUMENTO 2.

MEMORIA

“DISEÑO DE UNA APLICACIÓN DIDÁCTICA PARA LA MONITORIZACIÓN Y

SIMULACIÓN DEL ROBOT STAÜBLI RX-60”








8

UNIVERSIDAD DE LA RIOJA

ESCUELA DE INGENIERÍA INDUSTRIAL


TÍTULO “DISEÑO DE UNA APLICACIÓN DIDÁCTICA PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL


ESCUELA PARA LA QUE SE REDACTA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INDUSTRIAL, UNIVERSIDAD DE LA RIOJA

Dirección: Luis de Ulloa nº 20, Edificio Politécnico

Localidad: 26004 Logroño (La Rioja)

DIRECTOR CARLOS ELVIRA IZURRATEGUI

Correo electrónico: [email protected]

AUTOR FRANCISCO OCHOA BUENO

Titulación: Ingeniería Técnica Industrial especialidad en Electrónica Industrial

DNI: 16610968-T

Correo electrónico: [email protected]

Logroño a 31 de Enero de 2013

Firma del Autor del Proyecto:

mailto:[email protected]

mailto:[email protected]


Enero 2013 Ingeniería Técnica Industrial Electrónica - Universidad de La Rioja Francisco Ochoa Bueno

9

1. ÍNDICES DE MEMORIA

1.1 ÍNDICE DE CONTENIDO

DOCUMENTO 2. MEMORIA ......................................................................................................................... 7



2. OBJETO ......................................................................................................................................................... 11

3. ALCANCE...................................................................................................................................................... 12

4. ANTECEDENTES ......................................................................................................................................... 15





















10


9.5 LIBRERÍAS DE DESARROLLO ESPECÍFICAS ............................................................................................. 38 9.5.1 Librería de interfaz de usuario Qt ....................................................................................................... 38 9.5.2 Librería QExtSerialPort para el manejo del puerto serie ................................................................... 39 9.5.3 Librería gráfica 3D OpenSceneGraph ................................................................................................ 40




DOCUMENTO 3. ANEXOS ........................................................................................................................... 63




11

2. OBJETO

El objetivo de este proyecto se puede resumir en el desarrollo de una aplicación de

usuario que permita la monitorización de la posición del robot y la simulación de la

cinemática, del robot Staübli RX-60 de que dispone la Universidad de La Rioja (UR) y que se

encuentra ubicado en el laboratorio L-102 de la ampliación del edificio Departamental.

Es preciso señalar que el comportamiento cinemático durante la simulación no tendrá

por qué coincidir con el calculado por el controlador CS7 del robot real, ya que no son

conocidos los métodos de cálculo que emplea el controlador. Durante la monitorización la

aplicación se comunicará con el controlador real, de manera que en esa situación sí que podrá

interpretar el estado cinemático real del robot.

El desarrollo de dicha aplicación se apoyará en un estudio y análisis previo de

programas informáticos similares, así como de librerías que posibiliten la creación y manejo

de elementos 3D.

De esta forma los objetivos principales del proyecto quedan indicados en los siguientes

puntos:

1) Análisis de aplicaciones de monitorización y simulación de robots tanto comerciales

como gratuitas existentes.

2) Análisis y estudio de librerías gráficas existentes en el mercado para los sistemas

operativos.

3) Desarrollar una aplicación utilizando un lenguaje de programación de alto nivel para

simular los movimientos del robot Staübli.

4) Desarrollar una aplicación de comunicación con el robot, para el envío y la recepción

de comandos básicos.




12

3. ALCANCE

El ámbito de este proyecto se centra en el desarrollo de una aplicación informática que

permita comunicar al usuario de la misma mediante comandos básicos con el robot Staübli

RX-60 que se encuentra montado en la UR. El carácter de la aplicación se plantea de un modo

didáctico, teniendo una finalidad educativa en la materia de robótica y permitiendo que sea

empleada en las prácticas de la asignatura “Control y Programación de Robots” que se

imparte en la UR.

Para lograr dicho fin es necesario que se analicen las aplicaciones ya existentes y que

cumplen, al menos en parte, funciones similares. Es por tanto parte de este proyecto:

Analizar las distintas librerías gráficas 3d comerciales o gratuitas que permiten la

representación virtual de elementos.

o Describir sus características.

o Realizar una comparación entre ellas.

o Seleccionar aquella que mejor se adapta a las necesidades buscadas.

o Priorizar entre las que admitan varios sistemas operativos para permitir una sencilla

portabilidad a otros sistemas diferentes de aquél en el que se realiza.

o Priorizar entre las de alto rendimiento para poder trabajar casi a “tiempo real”.

Analizar programas existentes con una funcionalidad similar, tanto de carácter

educativo como profesional.

o Realizar una búsqueda de programas comerciales y gratuitos con finalidad

profesional o de aprendizaje.

o Describir las funcionalidades más notables.

o Establecer una comparación de sus características más destacables.

o Adoptar algunas ideas interesantes en referencia con la aplicación a desarrollar.

o Observar la distribución de elementos en la interfaz de usuario de los programas

para implementar en la aplicación a desarrollar una interfaz similar.

Obtener conclusiones sobre las librerías y programas que se van a adoptar para el

desarrollo final de la aplicación.

Adoptar un método de comunicación entre la aplicación de usuario y el controlador del

robot.




13

Diseñar una interfaz de aplicación fácil de comprender e intuitiva, en la medida de lo

posible, que facilite la sencillez del aprendizaje.

Desarrollar el código de la aplicación de forma propia y con la posibilidad de utilizar

librerías externas o partes de código desarrolladas por terceros. La aplicación permitirá:

o Controlar las acciones del usuario mediante la interfaz, así como visionar los datos

calculados.

o Generar un modelo cinemático del robot para calcular la cinemática directa e

inversa simulada del manipulador Staübli RX-60, ya que se desconocen los

cálculos internos que realiza el controlador asociado (tipo CS7B).

o Simular variaciones, en la cinemática directa e inversa, de los parámetros de

Denavit-Hartenberg.

Calcular la posición completa (posición xyz cartesiana + orientación) de cualquier

eslabón del robot o del extremo respecto a cualquier otro marco de referencia del

robot.

Calcular la posición completa (posición xyz cartesiana + orientación) de cualquier

eslabón del robot respecto a un marco de referencia absoluto o relativo al marco de

referencia del eslabón anterior o de otro cualquiera.

o Monitorizar la posición real de la herramienta del robot en el espacio cartesiano y

en el espacio articular, así como su estado abierto o cerrado.

o Representar la situación del robot en un entorno virtual 3D.

o Establecer comunicación con el robot de manera que permita el envío y recepción

de comandos sencillos.

o Realizar una interfaz simple para la ejecución sencilla y guiada de los comandos

básicos y más habituales disponibles para el controlador del robot.

o Implementar un editor de texto básico que permita la creación, guardado y envío de

programas.

o Deberá presentar dos modos de funcionamiento que serán el “modo de

monitorización” y el “modo de simulación”.

Durante la monitorización el modelo virtual intentará seguir en “tiempo real”

al brazo robot real, actualizando la posición en el menor tiempo posible.

En la simulación la aplicación trabajará de forma independiente al robot real y

se limitará a realizar cálculos del modelo cinemático y de trayectorias sencillas

sin necesidad de que coincidan con las reales. El “modo de simulación”

trabajará de forma teórica y su finalidad será didáctica. El motivo de esto es




14

evitar la complejidad de tener que identificar los cálculos internos del

controlador ya que no hay posibilidad de acceder a sus algoritmos de cálculo.

Selección de un determinado lenguaje de programación y de un compilador para

diseñar la aplicación. Comprenderá:

o Características y ventajas más destacables de los lenguajes de programación más

conocidos.

o Elección del lenguaje de programación que más se adecue a las necesidades del

proyecto que concierne.

o Selección del compilador que ofrezca mejores características y mayor simplicidad

para el desarrollo de este tipo de aplicación y su interfaz visual.

Empleo de un lenguaje de programación y de librerías que permitan efectuar cálculos

rápidos.

A ser posible, utilización de librerías que sean multiplataforma, de manera que se

pueda realizar una sencilla portabilidad entre distintos sistemas.

Determinar una arquitectura concreta para el diseño de la aplicación.

o Elementos hardware y software y su interrelación.

o Comunicación entre elementos.

Conocer las características básicas del hardware empleado.

Aspectos que quedan excluidos del ámbito de este proyecto son:

Acciones de control complejas sobre el robot real. Básicamente permitirá situarlo en

una determinada posición del espacio cartesiano o mover sus articulaciones un

determinado ángulo. Es decir, se limitará a monitorizar su posición actual y a permitir

el envío y recepción de comandos sencillos al controlador del robot.

Desarrollo a bajo nivel de un software que permita establecer la comunicación entre la

aplicación y el controlador del robot. Para llevar a cabo esta tarea se empleará un

control ActiveX o librería de comunicaciones ya creados, debido a las dificultades de

acceso al puerto serie en bajo nivel desde las versiones modernas de Windows.

Diseño 3D de los modelos para representación virtual del robot. Serán obtenidos de la

página del fabricante.

Detección de colisiones entre piezas del robot o con elementos del entorno.

Cálculos de la dinámica o de control.




15

4. ANTECEDENTES

A continuación se describen los componentes del proyecto que se toman como base de

partida o que vienen impuestos por las características de los elementos que lo componen, y

partir de los cuales y de los requisitos de diseño, se han determinado las diferentes

alternativas.

Prácticas de “Control y Programación de Robots”

Las prácticas de “Control y Programación de Robots”, que se imparten en la UR como

parte de dicha asignatura optativa, son la finalidad a la que se destina la realización

proyecto. Por tanto, la herramienta desarrollada se centrará en simular los conceptos

básicos de introducción a la robótica como la descripción de posición y orientación,

cambios entre distintos marcos de referencia y la cinemática directa e inversa del robot.

Se descartan conceptos más avanzados como la dinámica o el control del robot, que

quedan relegados a futuras ampliaciones o mejoras de la aplicación.

Brazo robot

El brazo robot real empleado para interactuar con la aplicación es un modelo industrial

RX-60 tipo PUMA de la marca STAÜBLI. Éste brazo robótico es el que se encuentra

disponible para las prácticas de “Control y Programación de Robots”.

Tipo de comunicación aplicación-controlador

La comunicación empleada será por puerto serie mediante protocolo RS-232 debido a

que es la que ya se encuentra instalada y disponible en el laboratorio donde se

encuentra el brazo robot. El controlador del robot también dispone como alternativa a

la comunicación serie de comunicación Ethernet. Sin embargo se opta por la

comunicación serie debido a los conocimiento con que ya cuenta el autor relativos a

ese tipo de comunicación y que se trata de una aplicación didáctica que no requiere una

eficiencia máxima.

Plataforma de trabajo

La plataforma de trabajo será Windows ya que es la que se encuentra instalada en la

mayor parte de los equipos de la UR. A esto hay que añadir la experiencia previa del

autor en este sistema. A pesar de que esta elección parezca condicionar altamente la

aplicación final, se buscará trabajar con librerías multiplataforma de manera que

suponga escaso trabajo trasladar el código a otro sistema.




16

5. NORMAS Y REFERENCIAS

5.1 DISPOSICIONES LEGALES Y NORMAS APLICADAS

Este proyecto está basado en la norma española UNE-157001, que establece una serie

de criterios generales para la elaboración de proyectos.

Para la comunicación entre la aplicación y el controlador CS7 del robot, se empleará

una comunicación de tipo serie siguiendo la norma RS232.

5.2 BIBLIOGRAFÍA

5.2.1 Libros o documentos

Gráficos 3D

[1] Richard S. Wright Jr., Michael Sweet. “OpenGL SuperBible Second Edition”. 2ª ed.,

Waite Group PRESS (2000).

[2] Josie Wernecke. The Inventor Mentor. 2ª ed., Addison Wesley (1995).

Programación

[3] H. M. Deitel, P. J. Deitel. Como programar en C/C++. 2ª ed., Prentice Hall (1995).

[4] Escuela Superior de Ingenieros Técnicos Industriales de San Sebastián. Aprenda C++

como si estuviera en primero.Universidad de Navarra, San Sebastián (1998).

[5] Programación en C/C++ Visual C++ 6. 1ª ed., Grupo Eidos (2000).

Robótica

[6] V+ Language Users Guide. Versión 11, Manual de referencia del lenguaje de

programación del robot Staübli RX-60.

[7] John Craig. Robótica. 3ª ed.

Simuladores de robótica

5.2.2 Páginas web

Webs sobre librerías de Gráficos 3D

[8] http://www.tecnun.es/asignaturas/grafcomp/presentaciones/pdf/libreriasGraficas6.pdf

http://www.tecnun.es/asignaturas/grafcomp/presentaciones/pdf/libreriasGraficas6.pdf




17

[9] http://ldc.usb.ve/~vtheok/cursos/ci4321/sd11/01_intro.pdf

[10] http://es.scribd.com/doc/59505333/a-Grafica-en-Tiempo-Real

[11]

http://sabia.tic.udc.es/gc/Contenidos%20adicionales/trabajos/MotoresGraficos/MotoresGrafic

os/introduccion.html

[12] http://www.ciens.ucv.ve/escueladecomputacion/documentos/archivo/65

[13] http://www.mendozajullia.com/papers/El%20pipeline%20grafico.pdf

[14] http://books.openlibra.com/pdf/WebGL.pdf

[15] Carlos González Morcillo, Javier A. Albusac Jiménez, Sergio Pérez Camacho, Jorge

López González, César Mora Castro. Desarrollo de videojuegos Programación Gráfica.

Universidad de Castilla- La Mancha.

[16] Neon Helium Productions. (Curso de programación en OpenGL). Disponible en:

http://nehe.gamedev.net/

Programación

[17] C++ con clase. (Curso de programación en C++). Disponible en: http://c.conclase.net/

Librerías de programación de interfaces

[18] http://www.americati.com/doc/ventajas_c.pdf

5.3 PROGRAMAS DE CÁLCULO

Generación de documentación

Word 2010

Photoshop CS4

Diagrama de Gantt

GanttProject 2.6.1

Cálculo matricial

Matlab 2008

Mathematica 7

http://ldc.usb.ve/~vtheok/cursos/ci4321/sd11/01_intro.pdf

http://es.scribd.com/doc/59505333/a-Grafica-en-Tiempo-Real

http://sabia.tic.udc.es/gc/Contenidos%20adicionales/trabajos/MotoresGraficos/MotoresGraficos/introduccion.html

http://sabia.tic.udc.es/gc/Contenidos%20adicionales/trabajos/MotoresGraficos/MotoresGraficos/introduccion.html

http://www.ciens.ucv.ve/escueladecomputacion/documentos/archivo/65

http://www.mendozajullia.com/papers/El%20pipeline%20grafico.pdf

http://books.openlibra.com/pdf/WebGL.pdf

http://nehe.gamedev.net/

http://c.conclase.net/

http://www.americati.com/doc/ventajas_c.pdf




18

6. DEFINICIONES Y ABREVIATURAS

6.1 DEFINICIONES

Applet

Cadena cinemática

Grados de libertad

Licencia GPL

Licencia LGPL

Licencia MIT

Layout

Robot tipo PUMA

Robot

Widget

6.2 ABREVIATURAS

DH: Denavit-Hartenberg

GDL: Grados de libertad

OSG: Librería gráfica OpenSceneGraph

UR: Universidad de La Rioja




19

7. REQUISITOS DE DISEÑO

Las premisas del proyecto se plantean el desarrollo de una aplicación bajo entorno

Windows® cuyos requisitos iniciales incluyen las siguientes funcionalidades:

Existirá una ventana de diálogo de simulación donde se implementará un modelo

virtual del robot en tres dimensiones mediante el uso de una librería gráfica.

Existirán unos paneles para el manejo básico de la cinemática directa e inversa del

brazo robot.

Todos los movimientos simulados en la aplicación serán convenientemente procesados

y enviados, en caso de que se estime oportuno, al brazo Robot Staübli RX60 (véase

Figura 1). Esto es, la aplicación debe poder trabajar independiente del brazo robot por

lo que deberá desarrollarse un modelo cinemático del brazo robot.

Figura 1 Brazo robot Staübli RX-60

La aplicación será didáctica, por lo que deberá ser de fácil utilización y de manejo

intuitivo.

La conexión con el controlador del robot será de tipo serie RS-232.




20

8. ANÁLISIS DE SOLUCIONES

8.1 LENGUAJE DE PROGRAMACIÓN

Dada la complejidad en cuanto a la necesidad de uso de varias librerías de programación

y al tamaño del proyecto, aun sin incluir muchas funcionalidades, se decide buscar un

lenguaje de programación con el que ya se tuviese cierta familiaridad, siempre que fuera

posible. Esta elección evita la necesidad de tener que partir de cero en el estudio del lenguaje

y permite que se programe con mayor fluidez y que se pueda estudiar y utilizar algún aspecto

más avanzado del lenguaje en cuestión.

Entre las opciones posibles se encuentran C++, Visual Basic y Java.

8.1.1 Alternativas analizadas

8.1.1.1 C++

C++ es un lenguaje de programación orientado a objetos con experiencia que dispone

una gran cantidad de estructuras de datos para programar, así como de librerías que poder

incluir. Ofrece una muy buena modularidad, permitiendo dividir las tareas en módulos que

posteriormente se pueden interconectar con facilidad.

Por otro lado se trata de un lenguaje que emplea expresiones algo complejas y que no es

fácil de aprender a utilizar bien, siendo especialmente problemático con el uso de punteros si

no tiene un conocimiento adecuado. Sin embargo existe muchísima información sobre su uso

y es fácil encontrar ejemplos para muchos problemas que puedan surgir.

Destaca especialmente en la eficiencia, ya que trabaja a más bajo nivel que los otros

lenguajes anteriormente mencionados, lo que hace posible que un mismo código equivalente

se ejecute con mayor velocidad en este lenguaje.

Es relativamente sencillo portar el código en C++ a otros sistemas.

8.1.1.2 Java

El lenguaje de programación Java, al igual que C++, es un lenguaje orientado a objetos

y contiene una gran cantidad de estructuras y tipos de datos y además tiene un excelente

soporte en referencia al uso librerías.




21

Es un lenguaje más moderno que C++, está muy estandarizado y en continua evolución.

Destaca por su portabilidad a otros sistemas y cuenta con una buena modularidad y es

relativamente sencillo en comparación con C++. Sin embargo su rendimiento es bueno, pero

no lo suficiente para aplicaciones que sean bastante exigentes.

8.1.1.3 Visual BASIC

Visual Basic ofrece la posibilidad de desarrollar aplicaciones de forma sencilla y en

muy poco tiempo. Uno de los aspectos destacables es que no necesita que se declaren las

variables de trabajo. Es fácilmente extensible mediante librerías DLL y componentes ActiveX

de otros lenguajes. Dispone de un editor de interfaz de usuario.

Tiene acceso directo a la API gráfica 3D DirectX, aunque también es posible trabajar

con OpenGL mediante el uso de un componente no oficial.

Es un lenguaje de programación muy extendido, por lo que es sencillo encontrar

información al respecto.

Su gran desventaja es que solamente trabaja en plataformas Windows y no existe forma

de exportar el código a otras plataformas. Su soporte para trabajar con programación

orientada a objetos es bastante pobre. Tampoco cuenta con capacidad para crear aplicaciones

multihilo, no al menos sin la necesidad de realizar llamadas a la API de Windows, y tampoco

permite incluir secciones de código en bajo nivel (ASM).

8.1.2 Solución adoptada

La solución adoptada finalmente ha sido C++, los motivos son los siguientes:

Una característica muy importante de este lenguaje es que es uno de los lenguajes de

alto nivel más rápido. A pesar de que la aplicación no requerirá una velocidad de

procesado muy alta, sí que es conveniente que se trabaje de forma rápida en el caso de

que se esté monitorizando en tiempo real la posición del robot.

Mayor conocimiento por parte del autor del proyecto de este lenguaje.




22

Es un lenguaje ampliamente utilizado y del que existe mucha información, así como

programas ya creados.

Ofrece buen mejor soporte para incluir librerías externas.

8.2 COMPILADOR

8.2.1 Soluciones estudiadas

En base al lenguaje de programación seleccionado (C++) y la plataforma de trabajo

(Windows), se establecen algunas alternativas para elegir el compilador más adecuado en el

desarrollo de la herramienta de simulación.

Las posibles alternativas analizadas son las siguientes.

8.2.1.1 Builder C++ 5

Este compilador ha sido uno de los completos para C++, si bien actualmente ha sido

claramente desplazado por el equivalente de Microsoft.

Independientemente de lo anterior, está compuesto por suficientes herramientas e

incorpora un editor visual de interfaces.

No existe tanta información disponible como en el caso Visual C++.

8.2.1.2 Visual C++

Microsoft Visual C++ proporciona un entorno de desarrollo eficaz y flexible para crear

aplicaciones basadas en Microsoft Windows y en Microsoft .NET. Se puede utilizar como un

sistema de desarrollo integrado o como un conjunto de herramientas individuales. Visual C++

se compone de compilador, una serie de bibliotecas estándar y otras propias como MFC.

La biblioteca MFC permite crear interfaces de forma visual, pero estos componentes

sólo pueden ser ejecutados en plataformas Windows en las versiones modernas de Visual

C++, por lo que esto no es una ventaja.

Incluye una buena compatibilidad para la administración de grandes proyectos y existe

mucha información referente a este compilador. Su compilador está considerado ser muy

eficiente.

Las versiones más modernas disponen de una versión gratuita muy completa.




23


La elección de compilador es Visual C++, concretamente la versión Profesional 2008.

Esta elección se basa principalmente en la facilidad de encontrar información y

soluciones a problemas para este compilador. Además es el compilador más utilizado en

entornos Windows y es muy eficiente.

Para la selección de la versión se pensó en la posibilidad de utilizar la versión 6 porque

se ejecuta con mayor velocidad y sus componentes visuales para el desarrollo de interfaces de

usuario no dependen de la plataforma .NET de Windows, sin embargo la versión 2008 está

más optimizada para equipos modernos y ha corregido muchos errores de versiones

anteriores. El problema del diseño de la interfaz se corrige incluyendo una librería externa de

diseño de interfaces de usuario que sea independiente de la plataforma.

Un importante motivo para elegir la versión 2008 Profesional es su capacidad para

poder integrar plugins externos, como el que se ha utilizado finalmente para trabajar con la

librería de creación de interfaces de usuario.

8.3 TIPO DE CONEXIÓN

8.3.1 Soluciones estudiadas

Las posibles soluciones para establecer comunicación entre el PC y el controlador CS7

del robot Staübli RX60 abarcan las opciones que ofrecen ambos dispositivos. El controlador

CS7 las opciones de que dispone son:

3 puertos de tipo serie RS232

1 puerto Ethernet con TCP/IP y NFS

1 puerto DeviceNet

El PC dispone en principio de comunicación tipo serie, cualquier otro tipo de

comunicación requerirá la instalación en el PC de la tarjeta de red correspondiente.


Como solución se ha elegido la comunicación serie, ya que se trata de un tipo de

comunicación sencillo de programar y que suele estar presente en cualquier PC y controlador

de robot industrial.

La velocidad que ofrece el puerto serie es suficiente para la aplicación desarrollada en

este proyecto.




24

8.4 DISEÑO DE LA INTERFAZ DE USUARIO

De entre las herramientas analizadas en el ANEXO II- Librerías para el desarrollo de la

interfaz de usuario”, se selecciona la librería Qt.

Existen otras similares, por lo que la decisión tampoco es muy decisiva, sin embargo

esta librería dispone de muchísima información bien organizada y estructurada en su página

web y numerosos ejemplos y foros. Es por ello, además de ser multiplataforma y disponer de

muchas útiles funciones que se selecciona esta.

8.5 LIBRERÍA GRÁFICA 3D

Se justifica a continuación la librería gráfica 3D empleada en este proyecto. Para ello se

toman las características más destacables de una serie de librerías 3D y se comparan mediante

una tabla.

Las librerías seleccionadas para analizar son las que aparecen en el “Anexo III-Estudio

de librerías gráficas existentes en el mercado”. Se han descartado las librerías de bajo nivel

debido a que son más complejas de utilizar cuando se trabaja con escenas que contienen

bastantes elementos y a que es más complejo utilizar características avanzadas. Por el

contrario los grafos de escena ofrecen mejor organización y permiten emplear características

avanzadas sin conocer en detalle qué es lo que sucede a bajo nivel.

8.5.1 Listado de librerías gráficas analizadas

Java 3D

Ogre

OpenGL Performer

Open Inventor

OpenSG

OpenSceneGraph



25

8.5.2 Tabla comparativa

CARACTERÍSTICAS JAVA 3D OGRE OPENGL

PERFORMER OPEN INVENTOR OPENSG OPENSCENEGRAPH

Multiplataforma Sí (se ejecuta en

navegador)

Sí. Windows, Linux ,

Mac IRIX, Linux, Windows IRIX, Linux, Windows

Sí. Windows, Linux,

Solaris, Mac

Sí. Windows, Linux, IRIX, FreeBSD,

Mac, Solaris, HP-Ux, AIX,

Playstation 2

Licencia Libre GPLv2 Libre MIT Comercial Comercial (primeras

versiones LGPL) Libre LGPL Libre LGPL

Eficiencia Alta Media Óptima Media Muy Alta Muy Alta

Facilidad de uso Alta Media Baja Alta Alta Alta

Lenguaje que usa Java

C++

No oficiales: Python,

Java, .NET

C, C++ C++, .NET, Java C++ C++, Lua, Java, Python

API que usa OpenGL / Direct3D OpenGL / Direct3D OpenGL OpenGL OpenGL OpenGL

Multiproceso Sí Sí Sí, avanzado No Sí. Sí

Funcionamiento en

navegador Sí

Existe un proyecto, pero

no es estable No No Sí, mediante plugin Sí, mediante plugin

Opciones avanzadas

- Configuraciones

multipantalla - Sonido 3D

- Shaders programables

- Realidad virtual

- LOD - Shaders

- Mallas avanzadas

- Animaciones tipo esqueleto

- Trayectorias

- Gestión prioridad de

objetos de la escena

- Especializada en multiprocesamiento

- Controles de interacción

de usuario con los objetos

- Mecanismos muy flexibles de descripción de

objetos

- Capacidades de renderizado avanzadas

Admite distribución entre varias estaciones

de trabajo.

LOD Culling de distintos tipos

Escalabilidad

Extensiones No Sí. Admite plugins de

forma fácil. No Sí

Sí. Diseñada para

adaptarse a los usuarios.

Sí

Archivos que admite CAD, VRML, X3D, OBJ,

3DS

XML, ZIP, PK3

Y varios formatos

típicos de imagen Tiene varios formatos

propios

OpenInventor,

OpenFlight, Designer’s Worbench, Medit, OBJ

Formato propio Formato propio y

VRML

Formato propio. Permite importer muchos otros(

VRML, OBJ, DXF, 3DS,

COLLADA, LWO, etc. )

Documentación

- Buena documentación.

- Existen bastantes libros. - Foro no muy activo

aunque existen otros.

- Muy buena documentación.

- Hay algunos libros

con ejemplos. - Foro muy activo.

No hay mucha información

Hay unos pocos libros y en

su web existe bastante

información.

Algo escasa.

- Documentación escasa, pero tiene abundantes ejemplos bastante

buenos.

- Hay algunos libros prácticos. - Foro muy activo.

Tabla 1 Comparación de distintas librerías 3D


26 Ingeniería Técnica Industrial Electrónica - Universidad de La Rioja Enero 2013



La librería 3D finalmente seleccionada es OpenScenGraph.

De entre todas las posibles opciones de la Tabla 1, se han descartado las librerías

comerciales.

Las librerías Java 3D y Ogre también quedan eliminadas debido a que su eficiencia es

un poco menor que la del resto y en este caso interesa la rapidez de procesamiento,

especialmente en el caso de futuras ampliaciones de la aplicación. Tampoco es imprescindible

la capacidad para incrustar la visualización en un navegador ya que queda fuera del propósito

de este proyecto.

Las librerías OpenSG y OpenSceneGraph son bastante similares en cuanto a

funcionalidad, pero se escoge OpenSceneGraph principalmente por:

Admitir una mayor cantidad de formatos de archivo de modelos y de imágenes.

La documentación se considera más completa. En el foro participan muchos usuarios y

responden con brevedad y los libros referentes son bastante buenos para iniciarse.

Es la que más formatos soporta. Incluso se está probando actualmente en el sistema

operativo Android.

8.6 ELEMENTOS Y FUNCIONALIDADES DE LAS

APLICACIONES DE ROBÓTICA

Dado el carácter básico de la aplicación y la complejidad de añadir funcionalidades

avanzadas, se descartan por falta de tiempo y se proponen algunas en futuras mejoras.




27

9. RESULTADOS FINALES

9.1 INTRODUCCIÓN

Una vez seleccionados los elementos que formarán parte de este proyecto se procede a

explicar la arquitectura general del sistema, es decir, la relación existente entre los elementos

que lo conforman y también se indican algunos aspectos destacables tanto del hardware como

del software que involucra este proyecto.

A modo de resumen, se citan las principales características que deberá poseer el

proyecto:

Se trata de realizar una herramienta útil y a la vez sencilla para aprender los principios

básicos sobre el manejo del brazo robot Stäubli RX60.

La aplicación estará desarrollada en lenguaje C++, siendo su implementación en el

compilador Microsoft Visual C++ 2008 bajo sistema operativo Microsoft® Windows

XP.

Las librerías empleadas facilitarán la portabilidad a otros sistemas.

Existen distintos programas para distintos sistemas que permiten controlar el brazo

robot, pero debido a la finalidad didáctica del sistema, se opta por el desarrollo de una

aplicación propia.

Se decide que la manera más intuitiva de desarrollar el conjunto de la aplicación sea a

partir de distintos menús de usuario y controles, dentro de los cuales se pueden acceder

a distintos cuadros de diálogo que permiten gestionar las distintas posibilidades de la

aplicación. Para ello se emplean los controles y objetos que ofrece Visual C++.

Se establecerá una comunicación tipo serie RS232 entre el PC donde se encuentre la

aplicación y el controlador CS7 del robot.

9.2 ARQUITECTURA GENERAL DEL SISTEMA

En la siguiente figura se puede apreciar un esquema sencillo de la arquitectura de la que

dispondrá el sistema:




28

Figura 2 Arquitectura general del sistema utilizado en el proyecto




29

9.3 ELEMENTOS DEL SISTEMA

9.3.1 Resumen de componentes empleados

Hardware

Robot PUMA Staübli RX-60

Controlador CS7 del robot

Cable de conexión serie RS-232

PC con conexión puerto serie

Software

Sistema operativo Windows XP

Compilador Visual C++ 2008 edición Profesional

Librería Qt para el desarrollo de la interfaz

Librería QExtSerialPort para realizar la comunicación vía puerto serie

Librería OpenSceneGraph para visualizar los gráficos 3D

Software Okino Polytrans 4.1.2 para realizar conversiones entre formatos de modelos

3D

Matlab 2008 para cálculos matriciales

Mathematica 7 para cálculos matriciales

Autocad 2011

9.3.2 Componentes hardware

9.3.2.1 Brazo robot Staübli RX-60

El brazo robot al que hace referencia este proyecto es un brazo de tipo PUMA del

fabricante suizo Staübli, concretamente se trata del modelo RX-60. Dispone de seis grados de

libertad, empleando los tres primeros para fijar la posición y los tres últimos, correspondientes

a la muñeca del robot, se utilizan para establecer la orientación.

El brazo RX60 está compuesto de eslabones o miembros interconectados por juntas o

articulaciones. Cada articulación está compuesta de un eje sobre el cual giran dos eslabones,

cuyos movimientos son generados por motores acoplados sin escobillas o motores brushless.




30

Este robusto y seguro ensamblaje asociado con un innovador sistema de conteo permite saber

todas las posiciones absolutas al mismo tiempo.

El brazo robot es suficientemente flexible y permite realizar una gran variedad de

aplicaciones como por ejemplo: manipulación de cargas, ensamblaje, procesos, aplicaciones

para deposición de gotas de adhesivo, aplicaciones de control, chequeo y limpieza de piezas,

pintura, etc.

Los distintos elementos del brazo son: La base (A), el hombro (B), el brazo (C), el codo

(D), el antebrazo (E) y la muñeca (F), véase la Figura 3 y la Figura 4.

Figura 3 Partes del robot Staübli RX-60




31

Figura 4 Equivalencias entre brazo humano y brazo robot

El brazo ensamblado, de este modo, contiene la motorización, soporte, mecanismos de

transmisión de movimiento, manojos de cable, circuitos neumáticos y eléctricos para su uso.

De simple construcción, el brazo RX60 consiste en una estructura rígida y revestida

para protegerse de agresiones externas. Su diseño está basado sobre módulos de transmisión.

En la Figura 5 se pueden observar las dimensiones correspondientes al robot.




32

Figura 5 Dimensiones del robot Staübli RX-60 (en mm)

9.3.2.2 Características técnicas

Condiciones de trabajo

Temperatura: +5ºC a +40ºC.

Humedad: 30% a 95% máximo, sin condensación.

Altitud: 2000 mm máxima.

Vibraciones: consultar al fabricante.




33

Peso

Brazo estándar: 44Kg.

Amplitud, velocidad y resolución

Articulación

Jt1 Jt2 Jt3 Jt4 Jt5 Jt6

Amplitud [º] 320 255 269 540 230 540

Distribución del rango

de trabajo [º]

A B C D E F

+/-160 +/-127.5

+/-134.5

+/-270

+120.5 /

-109.5

+/-270

Velocidad Nominal

[º/s] 287 287 319 410 320 700

Resolución angular

[º·10-3

] 0.724 0.724 0.806 1.177 0.879 2.747

Tabla 2 Límites de amplitud, velocidad y resolución

El brazo está preparado para obtener las máximas amplitudes angulares. No obstante, la

amplitud de las articulaciones puede ser limitada voluntariamente mediante software.

Figura 6 Brazo robot Staübli RX-60 instalado en la UR




34

9.3.2.3 Zona de trabajo del brazo robot

Figura 7 Volumen de trabajo del brazo robot

9.3.2.4 Características de carga

En las siguientes tablas (véase tabla Tabla 3 y Tabla 4) se refleja la capacidad de carga del

brazo en función de la velocidad y la inercia para las articulaciones 5 y 6 (las cuales pueden

apreciarse en la ).




35

Brazo estándar Capacidad de carga

A velocidad nominal 2,5 kg

A velocidad reducida 4,5 kg

Tabla 3 Capacidad de carga

Brazo estándar Inercia Nominal [Kg·m2]

Inercia Máxima [Kg·m2]

Articulación 5 0,0250 0,125

Articulación 6 0,0063 0,032

Tabla 4 Inercia de las articulaciones 5 y 6

Figura 8 Detalle de las articulaciones extremas del robot

9.4 CONTROLADOR CS7 DEL BRAZO ROBOT

El controlador CS7 del brazo robot dirige los movimientos del robot y recoge la

información de sus sensores. Se encuentra instalado en un armario.

Este controlador es multitarea, permitiendo la ejecución de hasta 7 tareas al mismo

tiempo, numeradas desde la tarea 0 a la tarea 6.

Cuando se envía un punto de destino al robot, es el controlador quien se encarga de

realizar los cálculos oportunos de trayectorias, velocidades y aceleraciones.




36

El medio de comunicación desde un PC hasta el brazo robot es a través de este

controlador. En este caso se utiliza una conexión serie RS-232 y el lenguaje que soporta este

controlador para poderle enviar instrucciones es el lenguaje V+.

Figura 9 Aspecto del Controlador CS7

9.4.1 Protocolo de comunicación V+

La capacidad de movimiento del brazo de robot y en consecuencia del lenguaje V+ es

realmente amplia, y la documentación proporcionada para el mismo también. Además, dicho

lenguaje de comunicación se puede emplear a través de distintos sistemas de comunicación,

pues se dispone de la posibilidad de comunicarse con el brazo a través del puerto serie, tarjeta

de red, etc.

De entre todas las posibilidades que ofrece el RX60 para realizar la comunicación entre

el sistema de control del brazo robot RX60 y un PC externo que desea controlar de manera

remota el brazo, se menciona y describe la forma de comunicación de más bajo nivel basada

en el establecimiento de un comunicación a través del puerto serie, enviando byte a byte por

medio del puerto RS232.




37

9.4.1.1 Configuración del puerto serie

Para poder implementar la comunicación vía puerto serie se debe conocer la

configuración del puerto serie y los caracteres de sincronismo del brazo RX60. En conjunto

de los mismos se presenta en la Tabla 5.

Parámetros del puerto serie RS-232 Configuración

Baudios (bits / s) 9600 bps

Bits de datos 8

Paridad Ninguna

Bits de parada 1 bit

Bit de stop 1 bit

Control de flujo Hardware

Tabla 5 Configuración de parámetros del puerto serie

9.4.1.2 Resumen de comandos para la comunicación con el brazo Staübli

RX-60

Como ha quedado mencionado anteriormente, la capacidad de movimiento del brazo de

robot y en consecuencia del lenguaje V+ es realmente amplia, y la documentación

proporcionada para el mismo también. Por tanto, se remite al lector al conjunto de los mismos

para obtener mayor información acerca de ellos.

A continuación se presentan, a modo de resumen, el conjunto de instrucciones básicas

que han sido utilizadas en la aplicación (véase Tabla 6).

Comando Acción

enable power Habilita el brazo para poder usarlo. A continuación hay que

pulsar el botón de encendido del controlador.

disable power Deshabilita el brazo.

where Permite conocer la posición del brazo.

point a

Permite definir un punto utilizando coordenadas de

orientación/posición cartesianas {x, y, z, yaw, pitch, roll}.

point #a Permite definir un punto utilizando ángulos de articulación

{Jt1…Jt6}.

speed %vel Permite definir la velocidad de sistema como porcentaje de la

velocidad máxima.

do ready Desplaza cada miembro del brazo a su posición de reposo.

do drive eje,

Dgrad,% vel

Desplaza el miembro eje el número de grados indicado en grad

al porcentaje de velocidad indicado en vel referido a la

velocidad de sistema.

do move a Desplaza el brazo a la posición indicada en el punto a, definido a




38

través de coordenadas de posición/orientación cartesianas.

do move #a Desplaza el brazo a la posición indicada en el punto #a, definido

a través de ángulos de articulación.

panic Aborta el movimiento del brazo.

Tabla 6 Resumen de comandos utilizados

Después de cada comando, que es tratado como una cadena de caracteres, es necesario

enviar los caracteres ‘\n’ y ‘ \r’ para indicar el fin de comando.

9.5 LIBRERÍAS DE DESARROLLO ESPECÍFICAS

En este capítulo se describen las características más destacables de las librerías de

desarrollo utilizadas para la implementación de algunas de los partes específicos de la

aplicación. Las librerías, en concreto, son las siguientes:

Qt, que permitirá realizar la interfaz de usuario y ampliar algunas de las

funcionalidades del lenguaje C++, ya que incorpora un gran conjunto de sublibrerías.

QExtSerialPort, librería para poder establecer comunicación entre el ordenador y el

controlador del brazo robot a través del puerto serie.

OpenSceneGraph, la cual permitirá desarrollar la interfaz virtual del brazo robot RX-60

en un entorno 3D.

9.5.1 Librería de interfaz de usuario Qt

La librería Qt está compuesta por un conjunto de módulos que abarcan distintas

funcionalidades, pero se centra especialmente en la creación de interfaces de usuario.

Posee una larga lista de características (ver ANEXO II- Librerías para el desarrollo de la

interfaz de usuario) y a continuación se destacan las más importantes.

Es una librería libre y de código abierto, por lo que se puede ver y modificar cualquiera

de los elementos que la componen. Es una librería madura que ya se ha empleado en múltiples

aplicaciones como Adobe Photshop Album, KDE, Mathematica, Scribus, Skype, VLC Media

Player, etc.

Un elemento muy interesante de esta librería es que es multiplataforma, por lo que el

mismo código puede ejecutarse en distintos sistemas.

Además posee un editor visual que permite configurar los elementos de la interfaz de

forma sencilla (ver Figura 10).




39

Figura 10 Qt Designer

Otro aspecto a tener en cuenta es la capacidad que tiene esta librería para trabajar con

“señales” y “ranuras”. Además de los métodos tradicionales de C++ para intercambiar datos

entre funciones, Qt permite conectar señales que envían unos determinados datos a funciones

que recogen y procesan la información, como si se tratase de dispositivos electrónicos

conectados entre sí intercambiando señales a través de sus pines.

9.5.2 Librería QExtSerialPort para el manejo del puerto serie

Esta librería hace posible la comunicación entre la aplicación y el controlador del brazo

robot (tipo CS7). El protocolo empleado es de tipo RS-232.

Consiste en una librería de comunicación que deriva de la librería Qt y por tanto se

integra adecuadamente.

En este caso se hace necesaria la utilización de esta librería de comunicación ya que en

las versiones modernas de Windows no es posible acceder directamente mediante funciones

de bajo nivel al puerto serie. Esto impide poder realizar una función propia para tener un

mayor control. Sin embargo no supone un gran problema ya que básicamente sólo es

necesario disponer de funciones de lectura, escritura, configuración y apertura y cierre del

puerto, lo cual ya está implementado en la librería QExtSerialPort.




40

9.5.3 Librería gráfica 3D OpenSceneGraph

La representación del modelo virtual del robot se ejecuta mediante el uso de la librería

OpenSceneGaph. Como se comenta en el Anexo I – Estudio de librerías gráficas existentes en

el mercado, es una librería multiplataforma para la representación de gráficos 3D de alto

rendimiento.

Figura 11 Aplicación ejecutándose y mostrando la visualización con OpenSceneGrpah

Esta librería tiene una alta eficiencia y permite trabajar con múltiples hilos de

procesamiento, lo que aporta un beneficio al rendimiento de la aplicación.

Mediante plugins que incorpora la librería es posible cargar los modelos 3D

descargados de la página web del fabricante del brazo robot.




41

9.6 FASES DE DESARROLLO

9.6.1 Introducción

Inicialmente, una vez seleccionados los elementos que forman parte del proyecto, se

dedica un tiempo al estudio de aspectos básicos del lenguaje de programación C++ y de las

librerías de software utilizadas.

Esto permite poder abarcar adecuadamente los siguientes pasos, que se han divido en

módulos o elementos más o menos desarrollados de forma independiente y que

posteriormente se han ensamblado para conformar el resultado final.

9.6.2 Fase del modelo matemático

Esta parte comprende el cálculo de la cinemática directa y de la cinemática inversa del

robot Staübli RX-60.

9.6.2.1 Posición, traslación y orientación

9.6.2.1.1 Posición

La posición se define en coordenadas cartesianas, quedando definido un punto en el

espacio por tres coordenadas: x, y, z.

( )

Figura 12 Descripción de la posición

9.6.2.1.2 Traslación

La traslación se describe como el desplazamiento de un punto. Para calcular traslaciones

utilizando signos, basta con hallar la diferencia de los correspondientes vectores de posición




42

del punto inicial y final. Para componer varias traslaciones sucesivas basta con sumar cada

una de ellas.

Las traslaciones producen un resultado independiente del orden en el que se realicen,

siempre y cuando no se haya producido ninguna rotación.

9.6.2.1.3 Orientación

Para situar un cuerpo en el espacio, además de la posición, se necesita una orientación.

La orientación se describe mediante un sistema de referencia ortonormal ligado al objeto

formado por tres vectores columna unitarios ortogonales entre sí, según las direcciones

principales de los ejes de referencia.

Como ejemplo, la siguiente matriz hace referencia al cambio de orientación del punto 2

visto desde el punto 1:

(

)

Figura 13 Descripción de posición + orientación

Las rotaciones no son independientes del orden en el tienen lugar. Se demuestra [ ] que

para rotaciones referidas al sistema relativo de la anterior transformación, la concatenación de

rotaciones da lugar a una matriz de rotación igual al producto matricial de todas ellas en el

orden en el que se han producido. Por el contrario, si las rotaciones son referidas a un marco

de referencia fijo, el resultado será el producto matricial de todas ellas en el orden inverso al

que se han producido.

Sistema de referencia relativo Sistema de referencia fijo

Tabla 7 Composición de rotaciones. Primero 0 a 1, después 1 a 2




43

Cabe destacar especialmente que la librería OpenSceneGraph no trabaja de esta forma.

Trabaja con filas en lugar de con columnas, de manera que los vectores son filas y se colocan

delante de las matrices en lugar de ir detrás. Por otro lado lo comentado en la Tabla 7 ya no se

cumple, sucede lo contrario. En OSG se suele trabar con matrices absolutas, por lo que resulta

más cómoda la multiplicación sucesiva en el orden en que se han producido las

transformaciones. Las matrices y vectores que utiliza OSG son traspuestas a las que

normalmente se usan en cálculos.

Existen diversas formas de describir la orientación, algunas de las más comunes y

empleadas en los cálculos de la aplicación son las siguientes. La notación empleada será la

tradicional, es decir, traspuesta a OSG.

Orientación mediante matriz de rotación

(

)

Esta forma ya se ha comentado antes. Cada columna representa un vector unitario, la

primera por la izquierda es i1 visto desde 0, la segunda es j1 visto desde 0 y la tercera k1 visto

desde 0. Son los nuevos vectores unitarios vistos desde el marco anterior a la rotación.

Orientación mediante ángulos de balanceo (roll), cabeceo (pitch) y guiñada (yaw)

Consiste en realizar un giro sobre X, otro sucesivo en Y y uno más en Z, todos ellos

respecto a un sistema fijo.

Figura 14 Composición de rotaciones en orientación tipo Roll-Pitch-Yaw




44

Orientación mediante ángulos de Euler ZYZ

Consiste en realizar un giro sobre el eje Z, otro sucesivo en Y y uno más en Z, todos

ellos respecto al nuevo sistema tras el cambio.

9.6.2.2 Transformaciones homogéneas

Las transformaciones completas se definen mediante las matrices homogéneas que

permiten describir el cambio de posición y de orientación al mismo tiempo. La matriz de

transformación homogénea es una matriz 4 x 4 que transforma un vector de posición

expresado en coordenadas homogéneas desde un sistema de coordenadas hasta otro sistema

de coordenadas. Una matriz de transformación homogénea se puede considerar que consiste

en cuatro submatrices:

(

)

En OSG evidentemente son traspuestas a lo indicado aquí.

9.6.2.3 Cálculo de la cinemática directa

Se trata de calcular la posición y orientación del extremo del robot a partir de la

selección de ángulos indicada para cada una de las articulaciones.

Primero se describen los parámetros de Denavit-Hartenberg que se utilizarán para

facilitar el cálculo de la cinemática directa.

9.6.2.3.1 Parámetros de las articulaciones

Un manipulador mecánico consiste en una secuencia de cuerpos rígidos, llamados

elementos, piezas o eslabones, conectados mediante articulaciones prismáticas o de

revolución (véase Figura 15 ), donde cada par elemento-articulación constituye un grado de

libertad.




45

Figura 15 Partes de un robot PUMA

De aquí que para un manipulador con N grados de libertad hay N pares articulación-

elemento con el enlace 0 (no considerado parte del robot) unido a una base soporte donde se

suele establecer un sistema de coordenadas inercial para este sistema dinámico, y el último

elemento está unido a la herramienta. Las articulaciones y elementos se enumeran hacia

afuera desde la base; así la articulación 1 es el punto de conexión entre el elemento 1 y la

base soporte. Cada elemento se conecta, a lo más, a otros dos, así pues no se forman lazos

cerrados.

En general, dos elementos se conectan mediante un tipo de articulación que tiene dos

superficies deslizantes, una sobre la otra, mientras permanecen en contacto. Únicamente son

posibles seis tipos diferentes de articulaciones, siendo la más común en manipuladores la

giratoria.

Figura 16 Sistema de coordenadas de elementos y sus parámetros




46

Un eje de articulación se establece (para la articulación i) en la conexión de dos

elementos (véase Figura 16). Este eje de articulación tendrá dos normales conectadas a él,

una para cada uno de los elementos. La posición relativa de tales elementos conectados

(elemento 1 - i y elemento i) viene dada por di que es la distancia medida a lo largo del eje

de la articulación entre las normales. El ángulo de articulación i entre las normales se mide

en un plano normal al eje de la articulación. De aquí que di y i se puedan llamar la distancia y

el ángulo entre los elementos adyacentes, respectivamente. Determinan la posición relativa de

los elementos vecinos.

Un elemento i (i = 1,…, 6) se conecta a lo más a otros dos elementos (por ejemplo, el

elemento 1 - i y el elemento 1 + i); así se establecen dos ejes de articulación en ambos

extremos de la conexión. El significado de los elementos, desde una perspectiva cinemática,

es que mantienen una configuración fija entre sus articulaciones, que se pueden caracterizar

por dos parámetros: ai y αi. El parámetro ai es la distancia más corta medida a lo largo de la

normal común entre los ejes de la articulación (es decir, los ejes zi-1 y zi ;para las

articulaciones i e 1 + i , respectivamente), y αi, es el ángulo entre los ejes de articulación

medidos en un plano perpendicular a ai. Así, ai y αi se pueden llamar la longitud y el ángulo

de torsión del elemento i, respectivamente. Determinan la estructura del elemento i .

En resumen, se asocian cuatro parámetros, ai, αi, di y i, con cada elemento de un

manipulador. Si se ha establecido un convenio de signo para cada uno de estos parámetros,

entonces constituyen un conjunto suficiente para determinar completamente la configuración

cinemática de cada elemento del brazo del robot. Obsérvese que estos cuatro parámetros van

apareados: los parámetros del elemento (ai, αi) que determinan la estructura del elemento y los

parámetros de la articulación (di, i) que determinan la posición relativa de los elementos

vecinos.

La matriz homogénea de la transformación consta de cuatro matrices simples:

( )

(

) (

) (

)

(

) (

)

9.6.2.3.2 Modo de cálculo

Para realizar el cálculo de la cinemática directa, se comienza analizando las

dimensiones del robot (Figura 5) y determinando la tabla correspondiente de los parámetros

de Denavit-Hartenberg (DH) (Tabla 8).




47

Para describir la relación traslacional y rotacional entre elementos adyacentes, Denavit y

Hartenberg propusieron un método matricial de establecer de forma sistemática un sistema de

coordenadas (sistema ligado al cuerpo) para cada elemento de una cadena articulada. La

representación de Denavit- Hartenberg (DH) resulta en una matriz de transformación

homogénea 4 x 4 que representa cada uno de los sistemas de coordenadas de los elementos en

la articulación con respecto al sistema de coordenadas del elemento previo. Así, mediante

transformaciones secuenciales, el efector final expresado en las «coordenadas de la mano» se

puede transformar y expresar en las «coordenadas de base» que constituyen el sistema inercial

de este sistema dinámico.

Figura 17 Pasos en la selección de los marcos de referencia para D-H

De acuerdo a las dimensiones del robot y los marcos de referencia seleccionados

mediante los pasos de la Figura 17, así como de la posición de referencia angular indicada en

la Figura 18 resultan los siguientes parámetros D-H:




48

Articulación \

Parámetro theta (º) d (mm) a (mm) alpha (º)

1 - 0 0 -90

2 - 49 290 0

3 - 0 0 90

4 - 310 0 -90

5 - 0 0 90

6 - 65 0 0

Tabla 8 Parámetros DH del robot Staübli RX-60

Figura 18Posición de ángulos nulos

9.6.2.4 Cálculo de la cinemática inversa

La cinemática inversa calcula los ángulos que deben tomar las articulaciones a partir de

una posición y orientación indicadas para el extremo de la pinza.

Para el cálculo de la cinemática inversa




49

9.6.3 Fase de la escena virtual

9.6.3.1 Modelo 3D del robot

En un principio, el modelado 3D del robot de decidió realizar empleando primitivas

básicas contenidas en la librería gráfica 3D o realizándolo paso a paso mediante algún

programa de CAD 3D a partir de los planos de sus dimensiones. Sin embargo, debido al

trabajo que supone y que se comprobó que el fabricante ofrecía los modelos ya creados, se

optó por descargarlos de su página web y convertirlos a un formato adecuado para su

utilización con OSG. Se pueden encontrar en la siguiente dirección:

https://secure.staubli.com/Intranet_Applications/Robotics/Group/RobDoc.nsf/ea05b3f4b301f597c1256d5

f005665e8/bc3707ec036c9f6bc12576c700327958/$FILE/page.html

Una vez obtenidos los modelos en formato STEP o IGES, son importados al programa

Okino PolyTrans que realiza la conversión a formato .obj que sí es aceptado por

OpenSceneGraph.

Figura 19 Programa PolyTrans 3D mostrando el eslabón 2 del robot

9.6.3.2 Montaje de la escena

La librería OSG permite mediante el desarrollo de un poco de código, incrustar un visor

en la interfaz de usuario diseñada con Qt. Este es uno de los motivos por el que se ha creído

https://secure.staubli.com/Intranet_Applications/Robotics/Group/RobDoc.nsf/ea05b3f4b301f597c1256d5f005665e8/bc3707ec036c9f6bc12576c700327958/$FILE/page.html

https://secure.staubli.com/Intranet_Applications/Robotics/Group/RobDoc.nsf/ea05b3f4b301f597c1256d5f005665e8/bc3707ec036c9f6bc12576c700327958/$FILE/page.html

50

correcto combinar estas dos librerías, además de que ya han demostrado su eficacia en otras

aplicaciones, algunas comerciales.

Para ello se crea incrusta un visor y se le proporciona capacidad de procesado en otro

hilo diferente al de la interfaz con la finalidad de evitar que ésta se congele en ocasiones o que

responda de forma lenta.

El siguiente trozo de código, corresponde a la definición del widget o elemento de la

interfaz que se encarga de la visualización. Se define con 4 vistas, aunque no es recomendable

utilizar más de una debido a problemas de rendimiento.

/* Inicialmente se muestra una unica vista. _nVistas solo contiene valor

nulo durante su inicializacion, permitiendo ejecutar en el arranque la

funcion que muestra las vistas 3D por pantalla. (si tuviera valor 1 al

inicio no se ejecutaria esa funcion tal y como esta implementada) */

_nVistas = 0;

/* El primer elemento (numero 0) no se emplea para que los indices coincidan

con los del numero de visor. */

_vistas.push_back(NULL);

// Usar modelado SingleThreaded para evitar problemas conocidos en Linux

_controladorVistas->setThreadingModel( threadingModel );

//Se crean los 4 visores para contener en la interfaz a las 4 vistas

for ( int i = 1; i <= 4; i++ ) {

_visores[i] = nuevoVisor( crearCamara(0,0,1000,1000), _raizEscena.get() );

}

// Configuracion de vista activa

mapeoVistaActiva = new QSignalMapper;

for ( int i = 1; i <= 4; i++ ) {

this->connect( _filtros[i], SIGNAL(onClicVista()),

mapeoVistaActiva, SLOT(map()) );

mapeoVistaActiva->setMapping( _filtros[i] , i );

_visores[i]->installEventFilter( _filtros[i] );

}

A partir de los modelos, se ha establecido un modelo 3D formado por transformaciones

en OSG mediante los nodos de tipo matrixTransform que corresponden a las matrices

obtenidas de los parámetros de D-H para cada eslabón. Una vez creadas están

transformaciones permiten leer las coordenadas y representar los ejes de los marcos de

referencia.

Para la adición de los modelos se han tenido que realizar transformaciones inversas que

compensen las relativas de cada nodo al que se acoplan para seguir su movimiento, ya que los

modelos venían fijos en una posición y no se pueden asociar a los nodos directamente, sus

transformaciones no se corresponderían con las del robot real.




51

9.6.4 Fase de interfaz de usuario

Se ha implementado una interfaz de usuario básica, que posteriormente ha sido

mejorada en otra versión con alguna funcionalidad, sin embargo no queda completa esta

última versión por límites en los tiempos de entrega. Se adjuntan las dos versiones.

9.6.4.1 Escena

En el centro de la ventana de la aplicación puede verse la zona de visualización del

modelo virtual del brazo robot.

Figura 20 Posibilidad de mostrar cuatro visores




52

Figura 21Aspecto de la aplicación

9.6.4.2 Cinemática Directa

En una versión más avanzada se incluye el cálculo mejorado de la cinemática directa en

un panel con información más completa.

Esta versión permite definir cuál de los marcos de cada eslabón del robot será el de

referencia y cual el observado. De esa forma se puede observar la posición y orientación no

sólo del extremo final respecto a la base, sino entre cualquier eslabón.




53

Figura 22 A la derecha panel de cinemática directa

9.6.4.3 Cinemática Inversa

El panel de cinemática inversa permite introducir la posición y orientación para una

cierta configuración de las posibles del robot. Las posibles configuraciones dependen de la

posición del brazo (a izquierdas o derechas), de la posición del codo (arriba o abajo) y de la

orientación de la muñeca (con ángulo de pitch positivo o negativo).




54

Figura 23 Diversas configuraciones del robot

Figura 24 Panel de la versión inicial de cinemática directa a la derecha abajo y en medio la

cinemática directa




55

Figura 25 Panel de cinemática inversa a la derecha

9.6.4.4 Comunicación

El panel de comunicaciones permite utilizar el puerto serie para comunicarse con el

robot. Se puede establecer comunicación mediante instrucciones del lenguaje V+ desde la

línea de envío o se ofrece también la posibilidad de enviar un programa completo.

Figura 26 Línea de envío por el puerto serie

Desde el panel se pueden enviar instrucciones de forma libre, de entre todas las que

admite el controlador en lenguaje V+. Desde el panel enviar programa es posible escribir




56

programas completos y enviarlos con sólo pulsar un botón, siempre y cuando se halla

establecido conexión con el puerto serie y esté abierto.

Figura 27 Ventana para enviar programas

Figura 28 Panel de puerto serie equivalente en la versión ampliada




57

9.6.4.5 Monitorización

A través del panel de puerto serie se pueden leer estados del robot, por ejemplo

utilizando las instrucciones “STATUS” o “WHERE”.

9.6.5 Fase de comunicaciones RS-232

Como ya se ha expuesto el control del propio brazo robot se realiza mediante conexión

a través del puerto serie.

Mediante el protocolo de comunicación RS-232 se envían los comandos al controlador

externos y/o se recibe información acerca de su estado.

Es obvio que si se desea disponer de esta funcionalidad, se debe poder acceder al puerto

serie del ordenador e implementar un procedimiento de control del mismo que permita tanto

enviar como recibir secuencias de caracteres que atendiendo al protocolo indicado, tendrán un

significado concreto. En este caso, como ya se ha comentado, se utiliza la librería

QExtSerialPort para tal fin y se programa una interfaz sobre ella.

Para acceder directamente al puerto serie se ha implementado en la interfaz el Panel

Serie que permite insertar y recibir de forma directa instrucciones y comandos como si de una

terminal se tratase.

Se presenta ahora de manera muy general algunos conceptos generales sobre el

funcionamiento de puerto serie. Sin embargo, mediante la librería utilizada existen clases

desarrolladas para el manejo del puerto serie, de modo que el control del puerto se realiza de

una forma muy externa de cara al programador.

9.6.5.1 El estándar RS-232

El puerto serie RS-232C, estaba presente en la mayoría de ordenadores actuales aunque

actualmente no es tan común y tiende a reemplazarse progresivamente por la comunicaciones

USB y Ethernet. Es una forma comúnmente usada para realizar transmisiones de datos entre

ordenadores. El RS-232C es un estándar que constituye la tercera revisión de la antigua norma

RS-232, propuesta por la EIA (Asociación de Industrias Electrónicas), realizándose

posteriormente un versión internacional por el CCITT, conocida como V.24. Las diferencias

entre ambas son mínimas, por lo que a veces se habla indistintamente de V.24 y de RS-232C

(incluso sin el sufijo "C"), refiriéndose siempre al mismo estándar.

El RS-232C consiste en un conector tipo DB-25 de 25 pines, aunque es normal

encontrar la versión de 9 pines DB-9, más barato e incluso más extendido para cierto tipo de

periféricos. En cualquier caso, los PCs no suelen emplear más de 9 pines en el conector DB-

25 (véase Figura 29). Las señales con las que trabaja este puerto serie son digitales, de +12V

(0 lógico) y -12V (1 lógico), para la entrada y salida de datos, y a la inversa en las señales de




58

control. El estado de reposo en la entrada y salida de datos es -12V. Dependiendo de la

velocidad de transmisión empleada, es posible tener cables de hasta 15 metros.

Figura 29 Conectores serie RS-232 (a la izquierda de 25 pines y a la derecha de 9)

Cada pin puede ser de entrada o de salida, teniendo una función específica cada uno de

ellos. Las más importantes se muestran en la presentada a continuación.

Pin Descripción

TXD Transmitir Datos

RXD Recibir Datos

DTR Terminal de Datos Listo

DSR Equipo de Datos Listo

RTS Solicitud de Envío

CTS Libre para Envío

DCD Detección de Portadora

Tabla 9 Funcionalidad de pines del puerto serie

Las señales TXD, DTR y RTS son de salida, mientras que RXD, DSR, CTS y DCD

son de entrada. La masa de referencia para todas las señales es SG (Tierra de Señal).

Finalmente, existen otras señales como RI (indicador de llamada), y otras poco comunes que

no se explican en este texto por rebasar el alcance del mismo.




59

Figura 30 Conectores serie

9.6.5.2 El puerto serie en el PC

El ordenador controla el puerto serie mediante un circuito integrado específico, llamado

UART (Transmisor-Receptor-Asíncrono Universal). A partir de la gama Pentium, la

circuitería UART de las placa base son todas de alta velocidad, es decir UART 16550A (con

buffers de E/S).

Para controlar al puerto serie, la CPU emplea direcciones de puertos de E/S y líneas de

interrupción (IRQ), estando definido en el estándar las direcciones de los puertos COM1 y

COM2, por lo que al añadir posteriormente otros puertos serie (COM3-COM4), las IRQ no

están especificadas. Cada usuario debe elegirlas de acuerdo a las que tenga libres o el uso que

vaya a hacer de los puertos serie.

Mediante los puertos de E/S se pueden intercambiar datos, mientras que las IRQ

producen una interrupción para indicar a la CPU que ha ocurrido un evento (por ejemplo, que

ha llegado un dato, o que ha cambiado el estado de algunas señales de entrada). La CPU debe

responder a estas interrupciones lo más rápido posible, para que dé tiempo a recoger el dato

antes de que el siguiente lo sobrescriba. Sin embargo, las UART 16550A incluyen unos

buffers de tipo FIFO, dos de 16 bytes (para recepción y transmisión), donde se pueden

guardar varios datos antes de que la CPU los recoja. Esto también disminuye el número de

interrupciones por segundo generadas por el puerto serie.

9.6.5.3 Configuración del puerto serie RS-232

El RS-232 puede transmitir los datos en grupos de 5, 6, 7 u 8 bits, a unas velocidades

determinadas (normalmente, 9600 bits por segundo o más). Después de la transmisión de los

datos, le sigue un bit opcional de paridad (indica si el número de bits transmitidos es par o

impar, para detectar fallos), y después 1 o 2 bits de stop. Normalmente, el protocolo utilizado

ser 8N1 (que significa, 8 bits de datos, sin paridad y con 1 bit de stop).




60

Una vez que ha comenzado la transmisión de un dato, los bits tienen que llegar uno

detrás de otro a una velocidad constante y en determinados instantes de tiempo. Por eso se

dice que el RS-232 es asíncrono por carácter y síncrono por bit. Los pines que portan los

datos son RXD y TXD. Las demás se encargan de otros trabajos: DTR indica que el

ordenador esta encendido, DSR que el aparato conectado a dicho puerto esta encendido, RTS

que el ordenador puede recibir datos (porque no está ocupado), CTS que el aparato conectado

puede recibir datos, y DCD detecta que existe una comunicación, presencia de datos.

Tanto el aparato a conectar como el ordenador (o el programa terminal) tienen que usar

el mismo protocolo serie para comunicarse entre sí. Puesto que el estándar RS-232 no

permite indicar en qué modo se está trabajando, es el usuario quien tiene que decidirlo y

configurar ambas partes. Como ya se ha visto, los parámetros que hay que configurar son:

protocolo serie (8N1)

velocidad del puerto serie a 9600 bps

protocolo de control de flujo

Este último puede ser por hardware (handshaking RTS/CTS) o bien por software

(XON/XOFF, el cual no es muy recomendable ya que no se pueden realizar transferencias

binarias). La velocidad del puerto serie no tiene por qué ser la misma que la de transmisión de

los datos, de hecho debe ser superior. Por ejemplo, para transmisiones de 1200 baudios es

recomendable usar 9600, y para 9600 baudios se pueden usar 38400 (o 19200).

9.7 POSIBLES MEJORAS O AMPLIACIONES FUTURAS

Lectura directa de la posición de forma automatizada.

Diseño de trayectorias sencillas mediante la unión de puntos por líneas rectas.

Adición de una lista grande de comandos.

Detección de colisiones.

Conexión remota.

Etc…




61

10. PLANIFICACIÓN DEL PROYECTO

A continuación se muestran las distintas actividades que conforman el proyecto y que

se deben realizar y superar para conseguir el desarrollo final. Se muestra también la

dependencia de cada actividad respecto a otras anteriores, de forma que se puede conocer a

partir de qué momento, a lo largo del desarrollo del proyecto, se puede comenzar una nueva

actividad.

CÓDIGO DEPENDENCIA DESCRIPCIÓN DE LA ACTIVIDAD DURACIÓN

(días)

A - Repaso y estudio de C++ 60

B - Cálculo del modelo cinemático 8

C - Análisis de librerías gráficas 3D 30

D - Análisis de herramientas de robótica 30

E - Análisis de librería para interfaz 30

F C Estudio de librería 3D seleccionada 60

G A Estudio de librería para interfaz seleccionada 60

H (grupo tareas) Desarrollo de la aplicación de software -

H.1 B, F Creación del modelo virtual 3D 30

H.2 G Desarrollo de la interfaz de usuario 60

H.3 H.1 Cinemática directa del robot 30

H.4 H.3 Cinemática inversa del robot 30

H.5 G Comunicación serie RS232 con el controlador 45

H.6 H.3, H.4, H.5 Creación de funciones de comandos V+ 30

I H Pruebas de simulación 15

J I Pruebas de monitorización 15

K I, J Redacción de la documentación 50

Tabla 10Pasos en la planificación del proyecto



62

Figura 31Diagrama de Gantt del proyecto

DOCUMENTO 2.

PLANOS DISEÑO DE UNA APLICACIÓN PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60


63

DOCUMENTO 3.

ANEXOS




64

“DISEÑO DE UNA APLICACIÓN DIDÁCTICA PARA LA MONITORIZACIÓN Y

SIMULACIÓN DEL ROBOT STAÜBLI RX-60”








65

0. ÍNDICE DE ANEXOS

DOCUMENTO 3. ...................................................................................................... ANEXOS ¡ERROR! MARCADOR NO DEFINIDO.

0. ÍNDICE DE ANEXOS .................................................................... ¡ERROR! MARCADOR NO DEFINIDO.

1. ANEXO I – ESTUDIO DE LIBRERÍAS GRÁFICAS EXISTENTES EN EL MERCADO¡ERROR! MARCADOR NO DEFINIDO.

1.1 CONCEPTOS GENERALES DE LAS LIBRERÍAS GRÁFICAS 3D .............. ¡ERROR! MARCADOR NO DEFINIDO. 1.1.1 Conceptos de librerías gráficas ............................................................. ¡Error! Marcador no definido.

1.2 LIBRERÍAS GRÁFICAS DE BAJO NIVEL EXISTENTES EN EL MERCADO PARA LOS DISTINTOS SISTEMAS

OPERATIVOS ................................................................................................. ¡ERROR! MARCADOR NO DEFINIDO. 1.2.1 Direct3D ................................................................................................ ¡Error! Marcador no definido. 1.2.2 OpenGL (+OpenGL Shading Language, +OpenGL ES) ....................... ¡Error! Marcador no definido. 1.2.3 VRML y X3D .......................................................................................... ¡Error! Marcador no definido. 1.2.4 WebGL ................................................................................................... ¡Error! Marcador no definido.

1.3 LIBRERÍAS GRÁFICAS DE ALTO NIVEL EXISTENTES EN EL MERCADO PARA LOS DISTINTOS SISTEMAS

OPERATIVOS ................................................................................................. ¡ERROR! MARCADOR NO DEFINIDO. 1.3.1 Java 3D .................................................................................................. ¡Error! Marcador no definido. 1.3.2 Ogre ....................................................................................................... ¡Error! Marcador no definido. 1.3.3 OpenGL Performer ................................................................................ ¡Error! Marcador no definido. 1.3.4 Open Inventor ........................................................................................ ¡Error! Marcador no definido. 1.3.5 OpenSG .................................................................................................. ¡Error! Marcador no definido. 1.3.6 OpenSceneGraph ................................................................................... ¡Error! Marcador no definido.

2. ANEXO IV- LIBRERÍAS PARA EL DESARROLLO DE LA INTERFAZ DE USUARIO¡ERROR! MARCADOR NO DEFINIDO.

2.1.1 Fast Light Toolkit (FLTK) ..................................................................... ¡Error! Marcador no definido. 2.1.2 GTK+ (Gimp Toolkit) ............................................................................ ¡Error! Marcador no definido. 2.1.3 Qt ¡Error! Marcador no definido. 2.1.4 wxWidgets .............................................................................................. ¡Error! Marcador no definido.

3. ANEXO V – ANÁLISIS DE APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN

COMERCIALES Y GRATUITAS EXISTENTES ........................... ¡ERROR! MARCADOR NO DEFINIDO.

3.1 APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN COMERCIALES EXISTENTES¡ERROR! MARCADOR NO DEFINIDO. 3.1.1 ABB RobotStudio ................................................................................... ¡Error! Marcador no definido. 3.1.2 FANUC Robotic’s ROBOGUIDE .......................................................... ¡Error! Marcador no definido. 3.1.3 KUKA Sim Pro ....................................................................................... ¡Error! Marcador no definido. 3.1.4 Microsoft Robotics Studio (MRS) .......................................................... ¡Error! Marcador no definido.

3.2 APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN EDUCATIVAS EXISTENTES¡ERROR! MARCADOR NO DEFINIDO. 3.2.1 RoboAnalyzer ......................................................................................... ¡Error! Marcador no definido. 3.2.2 RoboUALab ........................................................................................... ¡Error! Marcador no definido.

4. ANEXO IX – CÓDIGO DE LA APLICACIÓN .......................... ¡ERROR! MARCADOR NO DEFINIDO.

DOCUMENTO 4. PLANOS ............................................................. ¡ERROR! MARCADOR NO DEFINIDO.

0. ÍNDICE DE PLANOS .................................................................... ¡ERROR! MARCADOR NO DEFINIDO.




66

1. ANEXO I – ESTUDIO DE LIBRERÍAS

GRÁFICAS EXISTENTES EN EL MERCADO

1.1 CONCEPTOS GENERALES DE LAS LIBRERÍAS GRÁFICAS

3D

Una librería gráfica es un software que genera imágenes en base a unos modelos

matemáticos y unos patrones de iluminación, texturas, etc.

Su objetivo es conseguir la independencia del hardware, tanto de dispositivos de entrada

como de salida. También se busca independencia de la aplicación que la utiliza, de manera

que la librería es accedida a través de un interface único (al menos para cada lenguaje de

programación) para cualquier aplicación.

Las librerías gráficas pueden clasificarse en tres grupos:

Librerías de bajo nivel o de renderizado directo. Éstas acceden directamente al

hardware y a las API de los sistemas y son muy eficientes. Son muy flexibles, pero

complejas de utilizar.

Librerías basadas en grafos de escena. Suelen estar basadas en librerías de bajo nivel y

su utilización es más sencilla que las anteriores debido a que realizan una abstracción

mayor de los procesos. Permiten crear escenas virtuales en forma de árbol ramificado,

donde unos elementos pueden depender de otros anteriores.

Toolkits. Suelen ser las más fáciles de aprender a usar e incorporan múltiples

herramientas además de los gráficos 3D, como puede ser sonido, conexión a red,

control de periféricos, etc. Son herramientas más específicas, que no son tan eficientes

pero que permiten abarcar proyectos gráficos complejos que de otra forma serían muy

difíciles de realizar.

A continuación se presentan algunos de los conceptos que más aparecen cuando se

tratan temas relacionados con las librerías gráficas 3D.

1.1.1 Conceptos de librerías gráficas

Antialiasing:

El aliasing se refiere a problemas debidos a un muestreo insuficiente de primitivas,

texturas o shaders. El antialiasing es un método que evita el aliasing que es el efecto de

ver las líneas como si estuviesen dentadas o en escalera. El antialiasing revisa los

polígonos y difumina los bordes y vértices para evitar dicho efecto.




67

API:

El término API significa Interfaz de Programación de Aplicaciones y se refiere a una

librería que implementa cierta funcionalidad mediante una interfaz, con la cual el

programador puede acceder a dicha funcionalidad. Internamente una librería gráfica

hace uso de un API gráfico para acceder a la funcionalidad que proporciona el

hardware gráfico. En la actualidad los dos API’s gráficos que predominan son OpenGL

y DirectX.

Culling:

Codificado que logra que los objetos que no se ven en un determinado momento de la

proyección no sean procesados para que no tomen tiempo en el renderizado, así se

reduce la cantidad del trabajo. Hay varios tipos de culling que pueden ser utilizados.

Entre ellos, merecen citarse el culling de caras traseras (backface culling), culling por

pirámide truncada (frustum culling), culling por portales, culling por oclusión y culling

por contribución.

Doble buffering:

Ayuda a eliminar el parpadeo de las animaciones. Cada fotograma consecutivo en una

animación se construye en un buffer separado de memoria y mostrado solo cuando está

completo.

Frame:

En una animación, cada uno de los cuadros o imágenes generadas para simular

movimiento y que se reproducen de forma secuencial.

Level of Detail (LOD):

El nivel de detalle es una técnica imprescindible en gráficos 3D generados en tiempo

real, para poder mantener la velocidad de refresco de pantalla sin gastar tiempo

inútilmente. De lo que se trata es de tener modelos simplificados (en diferentes grados)

de un mismo objeto, de manera que se escogen los modelos a mostrar en cada

momento según la distancia a la que está del observador. Esto se hace por que no tiene

sentido dibujar un objeto muy complejo con centenares de polígonos si este objeto

ocupa muy poco en pantalla.

Modelado geométrico:

Proceso por el que se crean modelos virtuales de elementos reales. Pueden ser en 2D

mediante líneas, puntos y polígonos; o en 3D, mediante mallas poligonales y

subdivisión de superficies.




68

Modo inmediato:

El modo inmediato es un modo de trabajo de APIs gráficas en el que se da soporte a

todas las primitivas de procesamiento 3D que permiten las tarjetas gráficas (luces,

materiales, transformaciones, control de profundidad, etc).

Modo retenido:

El modo retenido es un modo de trabajo de APIs gráficas que se construye sobre el

modo inmediato y que presenta una abstracción de nivel superior ofreciendo

funcionalidades preconstruidas de gráficos como jerarquías o animaciones. El modo

retenido limita la libertad a los desarrolladores, siendo el modo inmediato el que más se

usa en las librerías de bajo nivel.

Normal Mapping:

Es la aplicación de una técnica 3D que permite dar una iluminación y relieve muy

detallado a la superficie de un objeto.

Pipeline:

Conjunto de procesos que se desarrollan desde el modelo de la escena virtual hasta que

se representa una parte de ella en la pantalla. Existen una serie de etapas funcionales

que se realizan secuencialmente, sin embargo algunas pueden ejecutarse en paralelo,

aumentando la velocidad de procesado de cada frame.




69

Figura 32Pipeline general en gráficos 3D

Las etapas principales son las siguientes.

o Aplicación: Se ejecuta en la CPU. Habitualmente se ejecutan tareas asociadas al

cálculo de la posición de los modelos 3D mediante simulaciones físicas, detección

de colisiones, gestión de periféricos, etc. En esta etapa se emplean estructuras de

datos de alto nivel que permiten reducir el número de polígonos que se envían a la

GPU.

o Geometría: Cada objeto 3D se transforma en diferentes sistemas de coordenadas.

Esta etapa utiliza hardware dedicado.

o Rasterización: A partir de los vértices proyectados (en Coordenadas de Pantalla) y

la información asociada a su sombreado obtenidas de la etapa anterior, la etapa de

rasterización se encarga de calcular los colores finales que se asignarán a los

píxeles de los objetos. Esta etapa utiliza hardware dedicado.

o Proyección en perspectiva.

Primitivas:

Representaciones básicas de las librerías gráficas. Unidades elementales a partir de las

cuales se construyen otros elementos más complejos.




70

Rasterizado:

Proceso por el cual se convierten las primitivas en fragmentos que quedan finalmente

como pixeles en el dispositivo de salida.

Renderizado:

Es el proceso de pasos que ejecuta una librería gráfica para representar una escena en

una pantalla. Se compone de:

o Muestra de la información que se quiere visualizar. Se realizan transformaciones

espaciales a los modelos, que dependen de la posición y orientación de la cámara y

se determina la visibilidad de los elementos.

o Se calculan y aplican sombras e iluminación.

o Texturas.

o Color.

Shaders:

La tecnología shaders es cualquier unidad escrita en un lenguaje de sombreado que se

puede compilar independientemente. Es una tecnología reciente y que ha

experimentado una gran evolución destinada a proporcionar al programador una

interacción con la GPU hasta ahora imposible. Los shaders son utilizados para realizar

transformaciones y crear efectos especiales, como por ejemplo iluminación, fuego o

niebla.

Stencil Buffer:

Buffer adicional al de color (pixel buffer) y al de profundidad (z-buffer) que existen en

las tarjetas gráficas actuales y que se utiliza para delimitar el área renderizada, además

de para otros usos más avanzados.

Textura:

Junto con la iluminación y sombreado dotan al modelo de más realismo. La textura son

imágenes que se ponen sobre los polígonos.

Viewport:

Región del plano de visualización que será mostrada en el dispositivo. Comúnmente

esta región es rectangular (ventana), y está delimitada en términos generales por dos

esquinas.

Z-buffering:




71

Mantiene registros de la coordenada Z de un objeto 3D. El Z -buffer se usa para

registrar la proximidad de un objeto al observador, y es también crucial para el

eliminado de superficies ocultas.

1.2 LIBRERÍAS GRÁFICAS DE BAJO NIVEL EXISTENTES

EN EL MERCADO PARA LOS DISTINTOS SISTEMAS

OPERATIVOS

1.2.1 Direct3D

1.2.1.1 Descripción

Direct3D es parte de DirectX (conjunto de bibliotecas para multimedia), propiedad de

Microsoft. Consiste en una API para la programación de gráficos 3D que está disponible tanto

en los sistemas Windows de 32 y 64 bits, como para sus consolas Xbox y Xbox 360.

En 1992, Servan Keondjian fundó RenderMorphics, una compañía que desarrollaba una

API de gráficos 3D llamada Reality Lab. Esta API se usaba en programas de CAD y

representación de imágenes médicas. En febrero de 1995, Microsoft compró RenderMorphics,

incorporando a Keondjian a la compañía para implementar un motor gráfico para Windows

95. El resultado fue la primera versión de Direct3D, incluida en DirectX 2.0 y DirectX 3.0.

El objetivo de esta API es facilitar el manejo y trazado de entidades gráficas

elementales, como líneas, polígonos y texturas, en cualquier aplicación que despliegue

gráficos 3D, así como efectuar de forma transparente transformaciones geométricas sobre

dichas entidades. Direct3D provee también una interfaz transparente con el hardware de

aceleración gráfica.

Se usa principalmente en aplicaciones donde el rendimiento es fundamental, como los

videojuegos o simulaciones, aprovechando el hardware de aceleración gráfica disponible en la

tarjeta gráfica.

Su principal competidor es OpenGL.




72

Figura 33. Capa de abstracción simplificada de Direct3D

1.2.1.2 Características principales

Como características principales de Direct3D, cabe recalcar su estructura basada

en objetos COM y la integración de la capa HAL. El HAL permite abstraer de las

peculiaridades de cada fabricante de hardware gráfico y centrarse en lo que interesa al

programador: las capacidades de aceleración hardware que posee el adaptador.

Gracias al uso del COM, Microsoft ha garantizado un sistema que a pesar de estar en

continua evolución, garantizará el funcionamiento de aplicaciones desarrolladas

con versiones antiguas del API.

Alto rendimiento.

Independencia del hardware.

Gracias al modelo COM es independiente del lenguaje, ya que los objetos COM son

simples librerías de código binario.

Sólo válido para las plataformas de Microsoft, siendo especialmente recomendado su

uso en estas plataformas para las cuales está más optimizado que otras librerías.

Más complejo de programar que OpenGL al no ocultar ciertos aspectos de bajo nivel,

pero al mismo tiempo esto aporta una mayor flexibilidad.

Actualizaciones de versiones relativamente lentas.

No es portable a otros sistemas.

No tiene estándar abierto.

Difícil de programar en C.

La librería DirectX donde se encuentra integrada Direct3D permite el manejo de

elementos de interacción con el usuario, como los eventos de ratón y teclado.




73

1.2.2 OpenGL (+OpenGL Shading Language, +OpenGL ES)


OpenGL es una interfaz de programación de aplicaciones (API) estándar desarrollada

inicialmente por Silicon Graphics en 1992 para el modelado y representación de gráficos 2D y

3D. Puede decirse que es una interfaz de software para acceder a funciones de hardware

gráfico.

En principio Silicon Graphics desarrolló una librería para sus estaciones graficas Iris

que disponían de un hardware especialmente optimizado para visualización de gráficos,

transformadas de matrices, etc. Con el uso de esta librería llamada "Iris GL" conseguían la

independencia del hardware entre sus distintas estaciones Irix.

Fue en 1992 cuando Silicon Graphics presentó una librería llamada OpenGL, evolución

de la antigua Iris GL. En su desarrollo pusieron especial énfasis en su portabilidad,

posibilidades de expansión y por supuesto su rendimiento.

Al tratarse de una tecnología abierta, su especificación no debe estar controlada por un

solo fabricante, sino que está dirigida por un consorcio independiente.

Durante años OpenGL se ha consolidado como la librería por excelencia para

desarrollar aplicaciones 2D y 3D con independencia de la plataforma o el hardware gráfico.

Una de las principales ventajas que aporta OpenGL es que se trata de un estándar

industrial. Gracias a la OpenGL ARB es realmente una tecnología abierta, lo que supone una

ventaja inestimable frente a otras tecnologías. El ARB se fundó en 1992 y estaba formado por

un nutrido conjunto de empresas interesadas en la creación de una API consistente y

ampliamente disponible, entre las que destacan, además de Silicon Graphics, grandes

compañías como Compaq, IBM, Intel, Microsoft, HP, Sun Microsystems, Apple, y

fabricantes de tarjetas gráficas como por ejemplo ATI, nVidia o 3D labs.

El comité ARB se encarga de gestionar el estándar OpenGL para que vaya

adoptando nuevas tecnologías, implementadas en un principio como extensiones; y a

medida que se aceptan, integrándose en sucesivas versiones del estándar. Las extensiones

no son más que llamadas a funciones que no pertenecen al estándar de OpenGL.

En septiembre del 2006 el comité ARB cambió de gestor, y ahora la

especificación de OpenGL la controla el consorcio de industria Khronos, dedicada a la

creación de API's para la creación y visualización de formatos multimedia en distintos

dispositivos y plataformas. Khronos gestiona otros proyectos relacionados con OpenGL




74

como por ejemplo OpenGL ES (Embedded System), para dispositivos móviles, portátiles,

etc.

Por otra parte, los años que lleva de desarrollo hacen que exista una extensa base de

conocimientos a su alrededor. Durante todo este tiempo se han producido cambios en la

librería, pero OpenGL siempre asegura una compatibilidad "marcha atrás". De esta forma, una

aplicación que se desarrolló usando la primera implementación de la librería, compilaría y

funcionaria con la última versión de la misma.

Gracias a la portabilidad de OpenGL las aplicaciones pueden ejecutarse en una amplia

variedad de arquitecturas y de soportes gráficos, sin que el resultado se vuelva inconsistente.

Actualmente OpenGL está disponible para una gran variedad de sistemas operativos, tales

como Unix, Windows, Mac OS, BeOS, etc. Existen implementaciones eficientes de OpenGL

suministradas por fabricantes para Mac OS, Microsoft Windows, Linux, varias plataformas

Unix, y PlayStation 3. También existen varias implementaciones software que permiten

que OpenGL esté disponible para diversas plataformas sin soporte de fabricante.

Debido a los cambios en el hardware gráfico, y a que OpenGL es básicamente un

interface de abstracción del hardware, parece muy probable que se quede anticuada pronto, es

decir, se podría suponer que en cuanto aparezca una nueva prestación (por ejemplo en las

tarjetas aceleradoras) OpenGL no sería capaz de proporcionar funciones al programador para

que este pudiese hacer uso de estas nuevas características en sus programas. Sin embargo

OpenGL se diseñó desde el principio para ser capaz de hacer frente a este problema, y gracias

a sus mecanismos de extensión, las nuevas funcionalidades se pueden ir introduciendo sin

problemas mientras que se respeta la compatibilidad con las versiones anteriores.

Figura 34 Versión simplificada del pipeline de OpenGL

Como extras añadidos a todo lo anterior se describe brevemente OpenGL Shading

Language y OpenGL ES.

OpenGL Shading Language permite el sombreado programable. Entre varias

funcionalidades que aporta, incluye la posibilidad de crear sombreados asociados al aspecto

de la geometría de un objeto 3D.

Por otro lado OpenGL ES hace posible emplear la API OpenGL en dispositivos

embebidos como móviles, portátiles, etc.




75

Figura 35 Capa de abstracción simplificada en OpenGL


Portabilidad entre distintos sistemas.

Capacidades de expansión que permiten mejorar o aumentar las funciones manteniendo

la compatibilidad con versiones anteriores. Sin embargo las extensiones son muy

dependientes del hardware.

Alto rendimiento.

Código libre.

Estándar abierto.

Reconocido como el estándar en la industria de los gráficos 3D.

Estandarización del acceso al hardware.

Independencia de la plataforma y del hardware.

La creación de escenas y efectos se basa en listas de procedimientos más que en la

descripción de la escena como ocurre en otras librerías.

No contempla el manejo de dispositivos relacionados indirectamente con la

interacción gráfica con el ordenador (como el ratón o el teclado, manejo de ventanas o




76

gestión de ficheros). Todas esas funciones y otras adicionales deber ser controladas por

la plataforma donde se trabaja.

OpenGL basa su funcionamiento en una serie de modos configurables y la

ejecución de una serie de primitivas de dibujo que no son más que la

realización de segmentos, polígonos, puntos o rectángulos de píxeles. Los modos

se seleccionan y configuran y las operaciones se realizan mediante el envío de

comandos gracias a la invocación de funciones (llamadas a métodos).

Los comandos OpenGL se organizan en secuencias y su procesamiento se realiza

siempre en el orden en que se reciben, aunque puede producirse un retraso entre

la ejecución de un comando y la representación de sus efectos.

OpenGL proporciona mecanismos para el control directo de las operaciones

fundamentales en el trabajo con gráficos en dos y tres dimensiones, incluyendo

tratamiento de luces, métodos de anti-aliasing, etc. Sin embargo, no proporciona

mecanismos de definición de objetos geométricos complejos, más bien permite

especificar cómo dichos objetos deben ser renderizados a partir de objetos

geométricos simples.

Queda bajo la responsabilidad del sistema sobre el que se ejecuta la aplicación el

control de las ventanas de la aplicación, del volcado del framebuffer al monitor (y la

realización de operaciones como la corrección del gamma, etc.).

No dispone de un formato de archivo propio.

Dispone de la librería GLUT que permite gestionar los eventos de ratón y teclado, así

como trabajar con elementos visuales de interfaz de usuario, todo ello de forma

independiente de la plataforma.

Relativamente sencillo de aprender.

Elevado número de nombres diferentes para una misma función (Direct3D

aprovecha la sobrecarga de nombres de función propias de la programación

orientada a objetos).

No tiene mucho soporte para todos los lenguajes de programación.

Tiene una arquitectura cliente – servidor, de manera que un programa (cliente) solicita

comandos y éstos son interpretados y procesados por el sistema OpenGL (servidor). No

es necesario que el servidor se sitúe en el mismo ordenador que el cliente, permitiendo

a la especificación OpenGL ser “transparente a la red”.




77

1.2.3 VRML y X3D


La primera propuesta pública sobre la posibilidad de crear un lenguaje que permitiese

recrear mundos virtuales surge en la conferencia sobre WWW que se celebró en Ginebra en

mayo de 1994, de la mano de Mark Pesce y Tony Parisi.

Ante el amplio apoyo recibido en dicha conferencia y junto a la ayuda de la revista

Wired, se estableció una lista de correo con el objetivo de conseguir una primera

especificación del lenguaje en unos cinco meses, de forma que se pudiese presentar en la

segunda conferencia Web en octubre de ese mismo año.

Tras una serie de debates en los que se discutieron diferentes propuestas, la alternativa

presentada por Silicon Graphics fue la que consiguió un mayor número de votos,

convirtiéndose de este modo en la base del nuevo estándar. Esta propuesta consistía en utilizar

como punto de partida el lenguaje en el que estaba basado Inventor, un producto de dicha

compañía. Finalmente, en octubre de 1994 se presentó la especificación de VRML 1.0.

Figura 36 Ejemplo de aplicación X3D ejecutándose en un navegador

Después de la conferencia de octubre, se fundó el VRML Architecture Group (Grupo

para la Arquitectura de VRML), también conocido como VAG. Este grupo tenía la misión de




78

ayudar en la clarificación e implementación de la especificación inicial de este nuevo

lenguaje. Con posterioridad, este organismo ha sido sustituido por el Consorcio VRML, entre

cuyos miembros se encuentran Netscape, Microsoft, IBM, Silicon Graphics, etc.

A principios de 1996, Silicon Graphics pone a disposición del dominio público QvLib,

el cual se convirtió en el primer parser VRML capaz de traducir el texto de una escena virtual

a un formato entendible por un navegador. Posteriormente aparecería WebSpace, el primer

navegador capaz de leer e interpretar todo el estándar VRML.

En la conferencia SIGGRAPH de 1996, se introdujeron modificaciones sobre el primer

estándar surgiendo lo que se conoce como VRML 2.0. Finalmente, en febrero de 2002, el

grupo de trabajo constituido a tal fin dio a conocer la nueva versión de VRML conocida como

X3D (eXtensible 3D). Las principales novedades de esta versión frente a la versión previa se

centran fundamentalmente en la integración de VRML 2.0 con XML. La publicación de la

especificación definitiva ocurrió en 2004.

La especificación VRML experimentó un rápido desarrollo:

VRML 1.0: Octubre de 1994.

VRML 2.0: Agosto, 1996.

VRML 97 (revisión menor de la versión 2.0): Abril, 1997.

X3D es la tercera generación de VRML.

La especificación es de 2004.

Su desarrollo sigue a día de hoy.




79

Figura 37 Ejemplo de mismo código en VRML y en X3D

X3D es una librería gráfica gratuita de estándares abiertos ISO en lo relativo al formato

de ficheros y la arquitectura de trabajo que permite representar y comunicar escenas 3D y

objetos utilizando XML.

Su estándar proporciona un sistema de almacenamiento, recuperación y reproducción de

contenido gráfico en tiempo real embebido en aplicaciones, todo con una arquitectura abierta

para soportar un amplio rango de ámbitos y escenarios definidos por el usuario.

Dispone de multitud de características que permiten que sea empleada en distintos

campos como visualizaciones científicas o ingenieriles, dibujo técnico, visualizaciones

médicas, simulaciones, multimedia, entretenimiento, educación, etc.

El desarrollo de comunicación en tiempo real de datos 3D entre aplicaciones de

escritorio y en red ha evolucionado desde sus comienzos como Virtual Reality Modeling

Language (VRML) a un estándar X3D considerablemente más maduro y eficiente.




80

1.2.3.2 Características principales de X3D

VRML es:

o Un formato de fichero de texto.

o Un lenguaje simple de descripción de formas 3D y entornos interactivos.

o Un estándar ISO de la web.

X3D es una adaptación de VRML para la sintaxis de Extensible Markup Language

(XML). Ello permite:

o Mejor integración con el resto de tecnologías del World Wide Web.

o Chequeos de validación, flexibilidad, fácil de leer por personas y máquinas.

Se pueden ver ficheros VRML/X3D utilizando:

o Un navegador VRML/X3D.

o Un plug-in VRML/X3D para un navegador HTML.

Dispone de XML integrado, clave para integrar la librería con servicios web, redes

distribuidas o transferir datos o ficheros entre aplicaciones y distintas plataformas.

Formado por múltiples componentes de manera que sólo es necesario cargar aquellos

que se vayan a utilizar, permitiendo bajo consumo en tiempo de ejecución.

Es extensible, es decir, permite agregar componentes para añadir funcionalidades extra.

A esto hay que añadir que cuenta que con grupos de extensiones para satisfacer

necesidades concretas.

Facilita la evolución o adaptación de contenido antiguo realizado en VRML97.

Multiplataforma. Funciona en cualquier dispositivo aun con pocos recursos, desde

móviles hasta ordenadores potentes.

Trabaja con gráficos de alta calidad y en tiempo real, siendo interactiva y permite

incluir audio y video a los datos 3D.

Está bien especificada, facilitando la creación consistente y libre de errores.

Elementos soportados:

o Gráficos 3D y shaders programables (formas geométricas por polígonos, por

parámetros, transformaciones jerárquicas, luces, materiales, texturas, pixel y vertex

shader, aceleración hardware).

o Gráficos 2d y CAD.




81

o Animaciones (temporizadores e interpoladores para realizar animaciones

continuas, animación humanoide, morphing).

o Audio espacial y video se pueden incluir en la escena.

o Interacción del usuario (pulsación y arrastre de ratón y pulsaciones de teclado).

o Navegación (cámaras, movimiento por la escena, detección de colisiones,

proximidad y visibilidad).

o Tipos de objetos definidos por el usuario.

o Posibilidad de cambiar la escena de forma dinámica por programación y lenguajes

de scripting.

o Permite acceder a escenas u objetos que se encuentren en otros sistemas

conectados a la red o establecer hipervínculos a elementos que se encuentren en

internet.

o Simulaciones físicas y comunicación en tiempo real.

1.2.4 WebGL


WebGL fue creado inicialmente por Mozilla, y más tarde estandarizado por el grupo

tecnológico Khronos Group, el mismo grupo responsable de OpenGL y OpenGL ES. El

primer prototipo fue diseñado por Mozilla en el año 2006 y a principios del 2009, Mozilla y

Khronos Group comenzaron el WebGL Working Group. Además de los ya mencionados,

actualmente los principales fabricantes de navegadores, Apple (Safari), Google (Chrome) y

Opera (Opera), así como algunos proveedores de hardware son miembros del grupo de trabajo

WebGL o WebGL Working Group. Todos ellos están interesados en verificar que el

contenido WebGL pueda correr tanto en sistemas de escritorio como en hardware de

dispositivos móviles.

WebGL (Web-based Graphics Library) es un estándar web multiplataforma para una

API de gráficos 3D de bajo nivel basado en OpenGL ES 2.0 y expuesto a través del elemento

canvas de HTML5. Esta API provee enlaces de JavaScript a funciones OpenGL haciendo

posible proveer contenido 3D acelerado en hardware a las páginas web. Esto hace posible la

creación de gráficos 3D que se actualizan en tiempo real, corriendo en el navegador.




82

Figura 38 Acuario virtual en WebGL

WebGL es un estándar que está creciendo rápidamente y cuyo uso se ha ampliado

considerablemente. Es una tecnología 3D muy prometedora, ya que se encuentra apoyada por

las grandes empresas como Google, Apple, Mozilla y otros proveedores de hardware. Y

aunque Microsoft no lo apoye por diversas razones, WebGL sigue creciendo e incluso se han

desarrollado plugins para que pueda correr en Internet Explorer, lo que indica un gran apoyo

hacia la evolución de WebGL por parte de los desarrolladores web.

1.2.4.2 Características

Tecnología moderna, todavía no lo suficientemente madura.

Las aplicaciones se ejecutan en el navegador, sin necesidad de instalación. Brinda la

posibilidad de contenidos 3D en la web sin la necesidad de utilizar plugins, ya que se

encuentra implementado en el navegador.

Es un estándar web.

Independencia del navegador utilizado.

La API de WebGL está basada en un estándar de gráficos 3D familiar y ampliamente

aceptado (OpenGL).

Puede existir algún problema de seguridad, aunque esto está siendo evaluado

actualmente. Se abre una línea directa desde Internet a la GPU del sistema, abriendo un

gran hueco de seguridad.




83

1.3 LIBRERÍAS GRÁFICAS DE ALTO NIVEL EXISTENTES EN

EL MERCADO PARA LOS DISTINTOS SISTEMAS

OPERATIVOS

A continuación se analizan las características de algunas de las librerías de gráficos 3D

de alto nivel más empleadas actualmente. Se ha tomado aquellas que tienen un propósito

genérico y se pueden emplear para desarrollar cualquier tipo de aplicación, aunque algunas de

ellas admiten el uso de extensiones que permiten ampliar ciertas funcionalidades concretas. Se

descartan herramientas complejas que incorporen varios módulos como pueden ser motores

de videojuegos.

1.3.1 Java 3D

Java 3D es una interfaz de programación de aplicaciones (API) basada en grafo de

escena para la plataforma Java.

Intel, Silicon Graphics, Apple y Sun ya desarrollaban APIs de grafos de escena en modo

retenido en 1996. Debido a que estas compañías deseaban una versión en Java, decidieron

colaborar para obtenerla, iniciándose así el proyecto Java 3D, que comenzó en 1997. La

primera versión apareció en 1998. Desde mediados de 2003 hasta mediados de 2004 se detuvo

su desarrollo y a partir del verano de 2004 Java 3D fue liberado como un proyecto

comunitario, es decir, sólo se liberaba para los miembros de la comunidad que por lo general

son universidades o marcas comerciales, no desarrolladores independientes.

Un grafo de escena Java 3D es un grafo directo no cíclico, es decir, un grupo de nodos

conectados mediante unas direcciones de manera que si se parte de cualquier vértice nunca es

posible acabar en el mismo. Puede ejecutarse tanto en OpenGL como en Direct3D.

Desde la versión 1.2 viene siendo desarrollado por Java Community Process (JPC) y

desde 2008 el código completo se considera libre y se desarrolla bajo licencia GPL v2.

En comparación a otras soluciones, Java 3D no sólo es una envoltura sobre una API

gráfica, sino que es una interfaz que encapsula la programación de gráficos usando una

aproximación real de orientada a objetos. De esta forma, una escena se construye tomando un

grafo de escena que es una representación de los objetos que van a mostrarse. Este grafo de

escena se estructura como un árbol que contiene varios elementos que son necesarios para

visualizar los objetos. Además, Java 3D ofrece un amplio soporte al sonido espacial.




84

Figura 39 Laboratorio virtual de robótica RoboUALab diseñado en Java 3D


Bases

o Su diseño de basa principalmente en el rendimiento. Cuando se realizan

distribuciones, se elige la alternativa que permite obtener mejores prestaciones en

tiempo de ejecución.

o Proporcionar un amplio conjunto de utilidades que permitan crear mundos en 3D

interesantes. Se evitó incluir características no esenciales u oscuras y tampoco

características que se podrían colocar directamente sobre Java 3D.

o Proporcionar un paradigma de programación orientado a objeto de alto nivel para

permitir a los desarrolladores generar sofisticadas aplicaciones y applets de forma

rápida.

o Proporcionar soporte a cargadores en tiempo de ejecución. Esto permite que Java

3D se adapte a un gran número de formatos de ficheros, como pueden ser formatos

específicos de distintos fabricantes de CAD, formatos de intercambio o VRML 1.0

(Virtual Reality Modelling Language) y VRML 2.0

Abstracción de alto nivel.

o Libera de las limitaciones de las implementaciones de bajo nivel.




85

o Permite realizar optimizaciones que no son posibles de conseguir con las APIs de

bajo nivel.

o Permite ajustar el renderizado al hardware instalado en el sistema.

o Aumenta el rendimiento al realizar procesamiento en paralelo durante la ejecución

de la escena.

Diseño

o Implementada por capas.

o Puede aprovechar las APIs gráficas 3D nativas de bajo nivel.

o Disponible para versiones OpenGL y Direct3D.

Dirigida a una amplia gama de hardware y software

o Admite renderizado software y trabajo con tarjetas gráficas de bajo coste.

o Estaciones de trabajo de gama media.

o Alto rendimiento.

Contenido de las escenas

o Descripción completa de toda la escena.

o Datos de las geometrías e información de los atributos.

o Visualización de datos necesarios para representar la escena desde un punto de

vista.

Se basa en estructura de grafo de escena multitarea.

Es multiplataforma.

Es una API genérica para aplicaciones en tiempo real, siendo válida tanto para juegos

como visualizaciones 3D.

Licencia libre GPLv2.

Soporta renderizado en modos retenido, retenido-compilado e inmediato.

Dependiendo de la plataforma, incluye renderizadores con aceleración hardware como

JOGL, OpenGL o Direct3D.

Dispone de un modelo de vistas (forma de presentar los datos) sofisticado basado en

realidad virtual con soporte para renderizado estereoscópico y complejas

configuraciones multipantalla.




86

Soporte nativo para cascos de realidad virtual.

Soporte para crear entornos de realidad virtual mediante múltiples proyecciones en

pantallas.

Sonido espacial 3D.

Shaders programables, soportando tanto GLSL como Cg.

Stencil buffer.

Capacidad de importar desde los formatos más típicos como 3DS, OBJ, VRML, X3D,

NWN y FLT.

1.3.2 Ogre

OGRE (Object-Oriented Graphics Rendering Engine) es un motor gráfico desarrollado

en C++, flexible y orientado a escenas diseñado para facilitar a los desarrolladores la tarea de

generar aplicaciones con gráficos 3D con aceleración hardware. Esta librería permite una

abstracción de todos los detalles de abajo nivel que utilizan otras librerías como Direct3D y

OpengGL y proporciona una interfaz basada en objetos mundo así como otras clases

intuitivas.

Figura 40 Ejemplo realizado con la librería OGRE

OGRE principalmente se utiliza en la creación de videojuegos, sin embargo ha sido

diseñada deliberadamente para ser una solución a la hora de realizar gráficos 3D genéricos.

En caso de ser necesarias otras funcionalidades como sonido, redes, colisiones y físicas,

inteligencia artificial, etc. es posible integrar otras librerías externas de forma sencilla.




87

Muchos motores gráficos pueden tener unas características muy destacables pero

carecen de un diseño coherente y de una documentación consistente que permitan utilizarlos

de forma eficiente. OGRE es diferente y está más enfocada al diseño que a ofrecer una larga

lista de funcionalidades, es decir, prioriza la calidad frente a la cantidad, ya que la primera es

mucho más difícil de añadir posteriormente.

Esta librería trabaja con diseño orientado a objetos y frecuentemente utiliza patrones de

diseño. El equipo encargado del desarrollo del núcleo se mantiene en un número pequeño de

personas de forma intencionada y todos sus miembros son ingenieros de software con amplia

experiencia en el mundo real durante años. Los parches se reciben desde miembros de la

comunidad, pero se someten a una rigurosa revisión de calidad y cohesión con la filosofía de

OGRE antes de poder ser aceptados.

OGRE no asume qué tipo de aplicación se desea desarrollar, sino que usa una jerarquía

de clases flexible que permite realizar cualquier tipo de escena, ofreciendo la posibilidad de

diseñar plugins para ajustar la organización de la escena.


Calidad en el método de diseño y trabajo de la librería.

Flexibilidad y posibilidad de crear o acoplar plugins.

Clara documentación y de calidad.

Existe una importante lista de librerías externa que pueden ser integradas y que aportan

funcionalidades extra.

Licencia MIT que permite utilizarla de forma libre siempre y cuando se distribuya una

copia incluyendo el contenido original, aunque no necesariamente las modificaciones

realizadas.

Productividad

o Interfaz diseñada de forma fácil de usar para minimizar el esfuerzo en el momento

de crear escenas 3D y además independiente de la implementación 3D, por ejemplo

Direct3D u OpenGL.

o Sistema extensible que hace que las aplicaciones se ejecuten de forma rápida y

simple.

o Requerimientos genéricos como la gestión del estado de renderizado, “culling

espacial”, etc. se realizan de forma automática para ahorrar tiempo de diseño.

o Diseño limpio y ordenado y documentación completa de todas las clases existentes.




88

o Motor gráfico probado y estable que ya se ha utilizado en varios productos

comerciales.

Plataformas y APIs 3D soportadas

o Soporte de Direct3D y OpenGL.

o Soporta las plataformas Windows (todas las versiones principales), Linux y Mac

OSX.

o Dispone de descargas de “prebuilds” en Windows para Visual C++ y

Code::Blocks, en Linux para gcc 3+ y XCode en Mac OSX.

Soporte de materiales y Shaders

o Potente lenguaje de declaración de materiales que permite mantenerlos fuera del

código.

o Soporta “vertex y shaders”. En ambos casos es posible programarlos en bajo nivel

usando código ensamblador o en alto nivel utilizando, DirectX9 HLSL, OpenGL

GLSL o Cg para ambos casos. Ofrece ayudas automáticas a ciertos parámetros que

se mantienen vinculados de forma constante como puede ser matrices de vistas,

información de estado de iluminación, posición espacial de la cámara, etc.

o Soporta el rango completo de operaciones de función fija tales como multitexturas

y fusionado multipase, generación de coordenadas de texturas y su modificación,

colores independientes y operaciones alpha para hardware no programable o de

bajo costo.

o Soporte para múltiples técnicas de materiales lo que conlleva que se pueden

diseñar efectos alternativos para un amplio rango de tarjetas y OGRE utilizará el

que mejor se soporte.

o Soporte LOD (Level Of Detail) en materiales. Esto permite que se consuman

menos recursos cuando la vista se aleja, de manera que se reduce el nivel de detalle

de los objetos.

o Carga de texturas en varios formatos de imagen: PNG, JPEG, TGA, BMP o DDS.

También se admiten algunos formatos inusuales como texturas 1D, texturas

volumétricas, mapas cúbicos (“cubemaps”) y texturas comprimidas (DXT o

S3TC).

o Las texturas pueden ser proporcionadas y actualizadas en tiempo real por plugins.

o Facilidad para utilizar texturizado en proyecciones.

Meshes (Mallas)




89

o Acepta datos de mallas en formatos flexibles, separación de los conceptos de

“vertex buffers”, “index buffers”, declaraciones de vértices y “buffer mappings”.

o Parches de tipo Bezier Bicuadrática para superficies curvas.

o Mallas progresivas (LOD), generadas de forma manual o automática.

o Tiene un creador de geometrías estáticas

Animación

o Animaciones avanzadas tipo esqueleto

o Soporte para animaciones flexibles de figuras.

o Animaciones de nodos de la escena para caminos o trayectorias de cámara y otras

técnicas similares, empleando interpolación de tipo splines cuando se necesita.

o Pistas genéricas de animación que admiten modificadores a través de plugins para

permitir animar cualquier parámetro a lo largo del tiempo.

Escenas

o Altamente configurables y de gestión flexible. Se utilizan clases predefinidas para

la organización de las escenas, aunque también se pueden utilizar subclases propias

para obtener un control total de la escena.

o Escenas jerárquicas. Los nodos permiten a los objetos ser unidos entre sí y hacer

que unos objetos sigan los movimientos de otros, crear estructuras articuladas, etc.

o Múltiples técnicas de renderizado de sombreado, altamente configurables y que

aprovechan al máximo cualquier aceleración de hardware disponible.

o Funciones de consulta de la escena.

Efectos especiales

o Sistema de composición que permite definir de forma sencilla efectos de

postprocesado a pantalla completa, mediante scripts o secuencias de comandos si

se desea.

o Sistema de partículas fácilmente extensible. Uso automático de agrupación de

partículas para obtener un máximo rendimiento.

o Soporta elementos para dibujar cielo u horizontes.

o Soporte de “billboarding” para gráficos tipo sprite. Esta técnica ajusta la

orientación de un objeto para que apunte hacia un objetivo, generalmente la

cámara.




90

o Dibujado de trayectorias.

o Los objetos transparentes se gestionan de forma automática (orden de renderizado

y opciones del buffer de profundidad se configuran de forma automática).

Funciones misceláneas

o Infraestructura común de recursos para la gestión de memoria y carga de archivos

(ZIP, PK3).

o Arquitectura flexible de plugins que permite al motor gráfico añadir extensiones

sin tener que ser recompilado.

o Los controladores disponibles permiten organizar de forma fácil los valores

derivados entre los objetos de la escena.

o Dispone de un depurador de memoria para evitar las fugas de memoria.

o Cuenta con ejemplos para integrar otras librerías externas, como ODE que permite

calcular físicas y colisiones.

o Conversor XML para convertir de forma eficiente en tiempo de ejecución formatos

binarios a/desde XML para intercambio o edición.

Otras características

o Existen algunos libros publicados que explican el manejo básico de la librería.

o Dispone de una completa referencia de la API y de manuales y tutoriales bastante

completos.

o Cuenta con un foro muy activo.

1.3.3 OpenGL Performer

OpenGL Performer o IRIS Performer es una librería comercial construida sobre

OpenGL con el propósito de permitir crear aplicaciones de simulación visual de alto

rendimiento en tiempo real. OpenGL Performer fue desarrollada por SGI, la cual continúa

manteniéndola y aportando mejoras.

OpenGL Performer apareció en 1991, año en el que un grupo del proyecto Open

Inventor de SGI decidió enfocarse en el rendimiento gráfico más que en la facilidad de

programación. Performer se centró en un trabajar como un grafo de escena que permitiera

reorganizar y cambiar la gestión de los elementos sobre la marcha, permitiendo que los

distintos pasos en la tarea de renderizado se ejecutaran en paralelo en múltiples hilos. Es




91

posible trabajar tanto en lenguaje C como en C++. Proporciona soporte para multiproceso,

permitiendo dividir el trabajo entre múltiples CPUs, gestionando su sincronización y

transferencia de información. Además, proporciona algunas características avanzadas tales

como la detección de intersecciones, la gestión de terrenos, morphing geométrico o incluso

una pequeña interfaz de usuario.

Diseñada para optimizar al máximo la utilización del hardarwe gráfico. Es una librería

muy orientada al mercado de la simulación visual, siendo su mayor prioridad la obtención de

tasas de refresco muy altas, llegando a mantener constantes tasas de 50 frames/segundo.

Esta librería está disponible en varias plataformas: IRIX, Linux, y varias versiones de

Microsoft Windows.

Figura 41 Ejemplo de quirófano renderizado en OpenGL Performer


Tiene licencia comercial.

Su objetivo principal se basa en el rendimiento, intentando mantener el número de

imágenes por segundo.

Destaca por su alta eficiencia, estando especialmente desarrollada para la ejecución de

tareas en múltiples hilos.

Permite que el desarrollador defina la importancia de los elementos de la escena, para

que en caso de que se produzca una caída del rendimiento se eliminen los elementos

poco importantes para mantener la tasa de refresco de imagen.




92

Es compleja de programar.

Trabaja en lenguaje C/C++.

1.3.4 Open Inventor

La librería Inventor es un sistema de definición, manipulación y renderizado de escenas

3D basada en la utilización de descripciones geométricas de alto nivel. La versión original se

denominaba Iris Inventor y funcionaba exclusivamente sobre máquinas SGI, estaba

implementada como una capa por encima de la librería IrisGl. En el momento que ARB creó

la especificación de librería OpenGl, también se realizó una descripción de Open Inventor,

una versión multiplataforma del antiguo Iris Inventor que utilizase como base a la librería

OpenGL.

Se trata de una API 3D de modo retenido orientado a objetos y que emplea el lenguaje

de programación C++. Actualmente también admite lenguaje .NET y Java.

Diseñada por SGI sobre 1988-1989 con la finalidad de proporcionar una capa de

abstracción para programar OpenGL.

Sus objetivos se basan en una mayor facilidad y comodidad a la hora de programar así

como en la eficiencia. Su estrategia estaba basada en la idea de que la gente desarrollaba

pocas aplicaciones en 3D debido al considerable tiempo que conllevaba su desarrollo con la

interfaz de bajo nivel IRIS GL. Lo que interesaba principalmente era conseguir una gran

facilidad de uso, incluso por encima de eficiencia de uso de recursos del sistema.

Gracias a la librería OpenGL, de bajo nivel, era ya posible tomar listas de polígonos

simples y renderizarlos tan rápido como fuera posible. Pero para que el programador pudiera

dibujar objetos más complejos era necesario que los dividiera en grupos y tomase cada uno de

éstos como una lista de instrucciones simples para ser enviada al motor de renderizado. El

problema que conlleva este método es que puede resultar algo complejo a la par que

ineficiente si no se tiene un conocimiento avanzado de la forma en que trabaja OpenGL. El

rendimiento depende mucho de la forma en que se envía esas instrucciones y de su orden y

además obliga a descartar los datos que no van a ser visibles en la imagen resultante. De esta

manera se requería una gran cantidad de código nada más que para iniciar un sencillo

programa.




93

Figura 42 Aplicación en Open Inventor de SGI

Open Inventor (OI) fue escrito para evitar este problema y para proporcionar una base

desde la que partir al desarrollar programas 3D. Dispone de una serie de objetos predefinidos

y se pueden crear subclases a partir de estos transformándolos de manera sencilla en otras

figuras o formas.

El “mundo” de trabajo se sitúa en una escena gestionada por OI, aplicando

optimizaciones de forma automática, como desechar del cálculo de una imagen los objetos

que quedan ocultos. OI también incluye una serie de objetos de control y sistemas para

aplicárselos a la escena facilitando la interacción.

OI dispone de un formato propio para almacenar las escenas y cuenta con funciones

para guardar y cargar de forma automática estos datos.

Por todo lo anterior, esta librería permite desarrollar programas en muchas menos

líneas de código. Por otro lado tiende a resultar más lenta que el código de bajo nivel ya que

es difícil optimizar bien de forma automática. Otro problema que surge es que no

necesariamente se trabaja con un único formato de archivo, por lo que se obliga a los

desarrolladores a escribir conversores que permitan el cambio de los datos.

Inicialmente propietaria de SGI posteriormente vendió una licencia de desarrollo a

Template Graphics Software (TGS) y en la actualidad depende de una empresa denominada

Visualization Sciences Group (VSG) que la adquirió.




94

Figura 43 VSG Open Inventor utilizado en una aplicación de Michelin

En la actualidad se continúa utilizando en muchos proyectos, especialmente orientados a

visualizaciones científicas o relacionadas con la ingeniería, habiendo demostrado que está

muy bien diseñada para un desarrollo efectivo de complejas aplicaciones 3D.

Inventor prima la usabilidad sobre el rendimiento. Está formado por un conjunto muy

elaborado de nodos de uso muy sencillo, pero no proporciona un buen rendimiento en tiempo

real (al menos comparado con otros sistemas como OpenGL Performer).


Orientada a objetos y escrita en C++.

Inicialmente sólo admitía el lenguaje de programación C++ pero las últimas versiones

también admiten .NET y Java.

Construida partiendo de la base de OpenGL.

Las primeras versiones de SGI tienen licencia GNU LGPL, las últimas de VSG tienen

licencia comercial aunque existe una versión de prueba con tiempo limitado.

Multiplataforma (IRIX, Linux, Windows).




95

Sistema de ventanas parcialmente independiente de la plataforma (X11+Motif, con

librerías de terceros también Win32, Qt/X11-Win-Mac, MFC, GTK, GLUT, etc.).

Modelo de programación basado en grafo de escena. Facilita la organización de

escenas 3D. Por tener una estructura de grafo de escena, permite organizar

jerárquicamente la información de forma sencilla.

Control simple de eventos para interacción con elementos 3D.

Alto rendimiento.

Define un formato de fichero estándar para el intercambio de datos 3D.

Proporciona estructuras gráficas predefinidas. Las formas básicas proporcionadas por

Inventor son cajas, conos, esferas y cilindros, además, permite definir textos 2D y 3D.

Proporciona utilidades gráficas ya definidas, por ejemplo rutinas para manejar

matrices.

Proporciona interacción con los objetos como selección, caja de manipulación y

manipulador de vistas. Proporciona un método integrado de selección y manipulación

interactiva de objetos.

Tiene mecanismos muy flexibles de descripción de formas y objetos. Permite definir

objetos a partir de curvas y superficies de tipo NURBS, y también a partir de mallas de

triángulos.

Tiene capacidades de rendering sofisticadas. Permite seleccionar entre distintos modos

de renderizado. Se pueden seleccionar distintas cámaras y distintos modos de

visualización interactiva.

Es extensible de tal modo que es posible crear nuevos tipos de primitivas y objetos.

Permite incorporar animaciones, teniendo nodos especialmente diseñados para ese

propósito.

No está diseñado para soportar multiproceso.

1.3.5 OpenSG

OpenSG es un sistema de grafos de escena que ofrece portabilidad entre plataformas y

que está diseñado para crear programas con gráficos en tiempo real.




96

Está desarrollada siguiendo los principios del código libre LGPL y puede ser utilizada

de forma gratuita.

Uno de los factores más importantes desde el punto de vista de sus desarrolladores es el

deseo de disponer de un sistema gráfico que pueda ser utilizado en multitud de plataformas.

Soporta las plataformas Windows, Linux, Solaris y MacOS X y está basada en OpenGL.

Figura 44 Aplicación creada con OpenSG que permite visualizar un tumor cerebral en renderizado

volumétrico obtenido a partir de una tomografía computerizada

Al igual que la mayoría de los grafos de escena, OpenSG cuenta con una serie de

características comunes a la mayoría de ellos como pueden ser crear nodos de distintos tipos,

posibilidad de cargar geometrías prediseñadas, situarlas en la escena y renderizarlas. Por

tanto, la mayor parte de elementos o funciones que están a disposición del usuario en esta

librería, en torno al 80%, también lo están en otras similares. Pero en lo que destaca es los

elementos que la diferencian, principalmente por su extensibilidad, funcionamiento seguro en

múltiples hilos de procesamiento y capacidad de distribuir el procesamiento entre varias

estaciones de trabajo.

La extensibilidad se refiere a la posibilidad de añadir nuevas funcionalidades incluso en

tiempo de ejecución, lo que permite que no se tenga que alterar el código fuente anterior. La

capacidad de procesamiento de múltiples hilos permite que se aproveche al máximo la

potencia de los procesadores actuales, de manera que cada hilo puede funcionar de forma




97

totalmente independiente y acceder a la escena sin que unos interfieran con otros. Por último,

el procesamiento distribuido permite repartir una escena para que cada parte sea procesada

por una estación y se pueda visualizar de forma eficiente en sistemas de visualización

grandes. El procesamiento distribuido también permite trabajar con grandes escenas en varias

partes y posteriormente unir las salidas en una única pantalla.

Sus inicios se basan en el proyecto Microsoft Farenheit al contrario que la librería Open

SceneGraph la cual inicialmente se basó en OpenGL Performer. OpenSG pretende hacer los

gráficos más generales y flexibles.


Librería de código abierto y gratuita (licencia LGPL).

Multiplataforma (Windows, Linux, Solaris y MacOS X).

Basada en OpenGL.

Alto rendimiento.

Capacidad de procesamiento en paralelo mediante múltiples hilos.

Posibilidad de procesamiento distribuido en varias estaciones de trabajo.

Diseñada para ser fácilmente adaptable a las aplicaciones mediante extensiones,

evitando que en cada nueva versión tenga que revisarse el código procedente de las

nuevas funcionalidades añadidas.

La documentación no es muy abundante, aunque cuenta con listas de discusión en su

página web para poder comentar aspectos con otros usarios.

1.3.6 OpenSceneGraph

OpenSceneGraph es una librería gráfica 3D de código libre y alto rendimiento, utilizada

por desarrolladores de aplicaciones en campos tales como la visualización de simulaciones,

videojuegos, realidad virtual, visualizaciones científicas y modelado.

Fue inicialmente creada por Don Burns en 1998 con la finalidad de poder realizar un

simulador de ala delta, que originalmente fue desarrollado para el sistema operativo IRIX de

SGI ejecutándose con Performer en un PC con Linux. Posteriormente creció y atrajo a una

comunidad en su desarrollo. Este aumento de interés llevó a que uno de los autores, Robert

Osfield, creara una empresa para su soporte. Desde entonces ha existido un continuo esfuerzo




98

para que continuara mejorando y se han ido lanzando de forma regular nuevas versiones que

ampliaban las funcionalidades anteriores, así como soporte para las nuevas plataformas de 64

bits en PC.

Se basa en el concepto de grafo de escena, ofreciendo un sistema orientado a objetos y

que se ejecuta por encima de OpenGL. Esto libera al desarrollador de la necesidad de

implementar y optimizar llamadas a elementos gráficos de bajo nivel y proporciona muchas

utilidades para el desarrollo rápido de aplicaciones gráficas.

Esta librería está creada completamente en C++ Estándar y en OpenGL y es

multiplataforma, soportando todas las plataformas Windows, y los sistemas operativos OSX,

GNU/Linux, IRIX, Solaris, HP-Ux, AIX y FreeBSD.

OpenSceneGraph se ha consolidado como el líder mundial en tecnología de grafos de

escena y se ha utilizado ampliamente en múltiples aplicaciones como visualizadores de

simulaciones, espaciales, científicas, y en industrias de conducciones de gas, videojuegos y

realidad virtual.

Esta librería Pretende poner a disposición de todo el mundo los beneficios de la

tecnología de los grafos de escena, ya sea a usuarios con fines comerciales o no. Está escrita

completamente en C++ Estándar y OpenGL, lo que hace uso total de la librería Standard

Template Library (STL) y patrones de diseño. Aprovecha el modelo de desarrollo de código

abierto para ofrecer una librería que es gratuita legalmente y que está centrada en las

necesidades de los usuarios.

Figura 45 Laboratorio virtual EOR utilizando en universidades de Moscú




99


Bases

o Rendimiento. Soporta multitud de funcionalidades para mejorar el rendimiento a

parte de contar con un código bien diseñado y probado. Permite aplicar ocultación

de elementos lejanos (“view-frustrum culling”), ocultación de elementos no

visibles (“occlusion culling”), ocultación de pequeños detalles (“small feature

culling”), ajustar el nivel de detalle (Level of Detail - LOD), ordenación de estados

de OpenGL, formar grupos de vértices, crear objetos de buffers de vértices, utilizar

el OpenGL Shader Language y “display lists” como parte del núcleo del grafo de

escena. También permite una sencilla personalización del proceso de dibujado,

como por ejemplo aplicar Continuos Level of Detail (CLOD).

o Escalabilidad. Puede funcionar tanto en dispositivos sencillos como en otros más

avanzados con múltiples procesadores y/o varias GPUs. Esto es posible debido a

que el núcleo del grafo de escena soporta múltiples contextos gráficos para las

“display lists” y para las texturas. Los pasos de ocultación y dibujado de elementos

han sido diseñados para almacenar localmente los datos renderizados y utilizar el

grafo de escena casi completamente como si se tratara de una operación de sólo

lectura. Esto permite que múltiples grupos ocultar-dibujar se ejecuten en varias

CPUs.

o Portabilidad. El núcleo del grafo de escena ha sido diseñado para tener una mínima

dependencia en cualquier plataforma específica, requiriendo poco más que C++

Estándar y OpenGL. Este hecho a permitido que esta librería pueda ser convertida

rápidamente a un amplio rango de plataformas (originalmente desarrollado en

IRIX, luego portada a Linux, después a Windows, y posteriormente a FreeBSD,

Mac OSX, Solaris, HP-UX, AIX e incluso Playstation 2).

El núcleo es completamente independiente del sistema de ventanas, lo que hace

más fácil a los usuarios añadir sobre el núcleo sus propias librerías específicas para

el manejo de ventanas. En la distribución de OpenSceneGraph, la librería

osgViewer ofrece soporte nativo a los sistemas de ventanas bajo Windows

(Win32), Unices (X11) y OSX (Carbon). La librería osgViewer además puede ser

integrada de fácilmente con otras herramientas de manejo de ventanas como Qt,

GLUT, FLTK, SDL, WxWidgets, Cocoa y MFC. En la documentación se incluyen

ejemplos de cómo realizar esa integración con las distintas herramientas.

o Productividad. El núcleo encapsula la mayoría de las funcionalidades de OpenGL

incluyendo las últimas extensiones, proporciona optimizaciones al renderizado y

añade un completo grupo de librerías que hacen posible desarrollar aplicaciones

gráficas de alto rendimiento de manera muy rápida. El desarrollador es liberado de

los elementos de bajo nivel y puede concentrarse más en el contenido y en cómo se

va a controlar ese contenido.




100

Es una librería clara, coherente y extensible debido a que combinando todo lo

aprendido de grafos de escena anteriores como Performer y Open Inventor, emplea

métodos modernos de ingeniería de software como los Patrones de Diseño, y tiene

una buena realimentación durante el ciclo de desarrollo. Todo esto facilita a los

usuarios la integración de OpenSceneGraph en sus propias aplicaciones.

Licencia

o Es de código libre y gratuita.

Otras

o Carga de datos. OpenSceneGraph dispone de la librería osgDB para la lectura y

escritura de datos, la cual soporta una amplia variedad de formatos mediante un

mecanismo extensible de plugins dinámicos. Actualmente incorpora 55 plugins

distintos para cargar varios formatos de datos 3D e imágenes.

Los formatos de datos 3D soportados incluyen COLLADA, LightWave (.lwo),

Alias Wavefront (.obj), OpenFlight (.flt), TerraPage (.txp) incluido el soporte de

paginación multiproceso, Carbon Graphics GEO (.geo), 3D Studio MAX (.3ds),

Peformer (.pfb), AutoCAd (.dxf), Quake Character Models (.md2). Direct X (.x),

Inventor Ascii 2.0 (.iv)/ VRML 1.0 (.wrl), Designer Workshop (.dw) y AC3D (.ac)

y el format native ASCII .osg.

Los formatos de imagen soportados son .rgb, .gif, .jpg, .png, .tiff, .pic, .bmp, .dds

(incluyendo grupos de imágenes comprimidas), .tga y quicktime (bajo OSX).

También es posible cargar una amplia gama de fuente de alta calidad con

“antialiasing” mediante el plugin freetype e imágenes basadas en fuentes a través

del plugin .txf.

Los usuarios también pueden generar bases de datos geoespaciales de gran escala

mediante el proyecto relacionado denominado VirtualPlanetBuilder y pueden

utilizar la paginación de bases de datos nativa de OpenScenGrpah para visualizar

estas bases de datos.

o Soporte de múltiples lenguajes de programación. Además de trabajar en C++,

existen adaptaciones a los lenguajes Java, Lua y Python disponibles como

proyectos de la Comunidad.

o Herramientas de nodos. También cuenta con un conjunto de librerías

independientes entre sí que pueden ser compiladas para insertarlas en la aplicación

o que se pueden cargar en tiempo de ejecución. Dispone de:

osgParticle – para crear sistemas de partículas (humo, niebla, etc.)

osgText – para textos de alta calidad con antialiasing




101

osgFX – conjunto de efectos especiales

osgShadow – sistema de sombras

osgManipulator – controles 3D interactivos

osgSim – efectos visuales centrados en la simulación

osgTerrain – renderizado de terreno

osgAnimation – animación de caracteres y de cuerpo rígido

osgVolume – renderizado volumétrico de alta calidad.

o Documentación.

La documentación no es muy abundante, aunque sí que contiene muchos

ejemplos bastante autoexplicativos. Dispone de un foro bien organizado y muy

activo.

Su página web tiene problemas en ocasiones y no responde durante un tiempo.

Existen algunos libros que explican de forma práctica y con ejemplos el

manejo básico de la librería.




102

2. ANEXO II- LIBRERÍAS PARA EL

DESARROLLO DE LA INTERFAZ DE

USUARIO

2.1.1 Fast Light Toolkit (FLTK)

Se trata de una librería para desarrollo de interfaces en C++ que soporta sistemas

Windows, Linux/Unix y MacOS.

La librería fue desarrollada teniendo en mente la programación de gráficos en 3D, para

ello tiene una interfaz a OpengGL, pero también es posible desarrollar interfaces de propósito

general.

Dispone de la mayoría de elementos necesarios para desarrollar interfaces modernas

relativamente simples. Sin embargo no cuenta con tantos widgets como otras librerías y no

emplea la apariencia nativa del sistema donde se utiliza.

Incorpora una aplicación para diseñar visualmente la interfaz, denominada FLUID.

Soporta personalización de la interfaz mediante estilos y temas. Soporta gráficos 3d vía

OpenGL y la emulación de GLUT.

Se trata de una librería de rápido funcionamiento, muy bajo consumo de memoria y que

ocupa muy poco tamaño, siendo especialmente útil para utilizar en sistemas Linux embebidos.

La priorización de velocidad y consumo de recursos con que cuenta sin embargo suponen

algunas restricciones de apariencia y funcionalidad.

Su licencia es LGPL, gratuita y de código libre, siendo posible compartir y modificar el

código pero debiendo mantenerlo libre.




103

Figura 46 Ejemplo de interfaz en FLTK

Dispone de manuales online y en pdf y de foros de usuarios.

http://www.fltk.org/index.php

2.1.2 GTK+ (Gimp Toolkit)

Es una librería multiplataforma que ofrece multitud de elementos de interfaz, que se

puede emplear tanto para pequeños proyectos como para grandes.

Principalmente pensada para entornos gráficos GNOME, XFCE y ROX, se puede usar

también en Windows, Linux, MacOS y otras plataformas móviles (OpenMoko para teléfonos

móviles y Maemo para tablets).

Escrita en C, pero permite trabajar también con otros lenguajes como, C++, C#, Perl,

Python, Java, Javascript, PHP, Ruby, Pascal, R, etc. Con la herramienta “Glade GUI Builder”

es posible diseñar interfaces en GTK+ de forma visual e interactiva.

La licencia que posee es LGPL, software libre y gratuito que debe mantenerse libre aun

cuando se emplee dentro de aplicaciones propietarias por las cuales se cobre.

http://www.fltk.org/index.php




104

Figura 47 Ejemplo de interfaz en GTK+

Se trata de una librería estable ya que lleva más de una década de desarrollo (desde

1998), tiene buen rendimiento y es soportada por una gran comunidad de desarrolladores.

Trabaja con programación orientada a objetos y admite temas y estilos, además de

aspecto del sistema nativo.

Otras funciones que admite gracias a estar basada en la librería GLib son: trabajo con

objetos, dispone de un” loop” principal, soporte de “threads” o hilos de procesamiento en

paralelo, “timers”, listas, vectores, tablas, árboles, dispone de intérprete XML, etc.

Por sus características es fácilmente adaptable a sistemas móviles o embebidos.

Cuenta con una amplia documentación con imágenes y algunos ejemplos de código. A

esto hay que añadir algunos tutoriales los cuales no están todos disponibles o completos ya

que se van completando poco a poco por la comunidad. Existe también algún libro para

aprender a utilizar esta librería.

Existen foros bastante activos.

http://www.gtk.org/

2.1.3 Qt

http://www.gtk.org/




105

Librería multiplataforma ampliamente utilizada para desarrollar aplicaciones con

interfaces gráficas de usuario. El hecho de que disponga de numeras sublibrerías con

múltiples funciones hace que también se emplee ampliamente para desarrollar programas sin

interfaz gráfica como herramientas en línea de comandos y consolas para servidores.

Figura 48

Se trata de software libre y de código abierto con licencia LGPL, aunque existen

también licencias comerciales. Soportada por la comunidad y varias empresas como Nokia,

Digia y otras.

Es utilizada en el entorno de escritorio KDE para sistemas como GNU/Linux o

FreeBSD entre otros.

De forma nativa emplea como lenguaje de programación C++, pero adicionalmente

puede ser utilizado en varios otros lenguajes a través de “bindings”. También se emplea en

sistemas informáticos embebidos en automoción, aeronáutica y aparatos domésticos.

Funciona en todas las principales plataformas y cuenta con un amplio apoyo.

Su API dispone de métodos para acceder a bases de datos mediante SQL, uso de XML,

soporte de red, gestión de múltiples hilos de procesamiento, manipulación de archivos de

forma unificad en las distintas plataformas, manejo de ficheros y directorios y estructuras de

datos típicas.

Es utilizada en programas comerciales (Autodesk Maya, Google Earth, Siemens,

Mathemathica, etc.) dado su buen aspecto, así como eficiencia y funcionalidad. Por el

contrario tiene un tamaño considerable así como las aplicaciones creadas. El consumo




106

El procesado de las señales puede consumir bastantes recursos del sistema.

Se trata de una librería muy grande, que si bien aporta muchos elementos y soluciones

es costosa de conocer en profundidad.

Sin embargo aporta flexibilidad, transparencia y fácil portabilidad.

El código escrito es limpio y claro. Con pocas instrucciones se pueden ejecutar

bastantes órdenes, al contrario que con otras librerías como GTK que precisa escribir bastante

código, sin embargo a veces el rendimiento de la aplicación final es algo peor que con otras

librerías.

2.1.4 wxWidgets

Se trata de una librería en C++ que permite a los desarrolladores crear aplicaciones en

Windows, OS X, Linux y Unix en arquitecturas de 32 o 64 bits, así como en otras

plataformas incluyendo Windows Mobile, iPhone SDK, y GTK+ embebido.

Es posible programar con otros lenguajes, siendo algunos de los más populares Python,

Perl y Ruby.

Al contrario que otras herramientas multiplataforma emplea el estilo nativo ya que

accede a la API de la plataforma en la que se encuentra en lugar de utilizar emulación de la

interfaz.

Contiene widgets simples y otros más avanzados como árboles, listas, soporte

multidocumento, barras de herramientas, etc. Admite extensiones y mejoras.

Maneja un sistema avanzado de eventos, permitiendo definir eventos propios. Al

contrario que la librería Qt no requiere un preprocesador de eventos específico.

Tiene otras características avanzadas como: soporte para multithread, bases de datos,

modelo vista/documento, manejar de archivos y directorios, manejo de HTML y redes

TCP/IP, gráficos 2d, integración de OpenGL, diseño de diagramas, idiomas, etc.

Cuenta con herramientas que ayudan a depurar las aplicaciones desarrolladas. Soporta la

mayoría de los compiladores.

Existen herramientas que permiten diseñar la interfaz de forma visual con wxWidgets,

algunas gratuitas como wxFormBuilder, wxDev-C++, o wxGlade y otras propietarias como

wxDesigner o wxForms.

Su licencia es gratuita, libre y de código abierto. Es una librería madura.




107

Cuenta con un extenso manual donde se detallan las clases y métodos y que contiene

algunos ejemplos. Dispone de un foro bastante activo.

Se trata de una librería con amplia experiencia, ya que se lleva desarrollando desde el

año 1992.

Es bastante rápida siempre y cuando la aplicación no sea excesivamente grande, pero

consume bastante memoria.




108

3. ANEXO III – ANÁLISIS DE APLICACIONES

DE MONITORIZACIÓN Y SIMULACIÓN

COMERCIALES Y GRATUITAS EXISTENTES

3.1 APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN

COMERCIALES EXISTENTES

3.1.1 ABB RobotStudio

RobotStudio es una aplicación de PC destinada al modelado, la programación fuera de

línea y la simulación de células de robot.

La herramienta ABB RobotStudio permite trabajar con los robots de la marca ABB,

haciendo posible la realización de tareas reales con conexión al robot o la simulación de esas

tareas mediante el uso de un controlador virtual.

También incorpora un modo de programación offline con la Tecnología de Robot

Virtual (VRT) que permite trabajar como si el robot real estuviese en el PC. Este modo

permite aumentar la rentabilidad de la inversión en sistemas de robots, permitiendo programar

los robots en un PC sin necesidad de parar la producción. También se pueden preparar los

programas de los robots anticipadamente, lo que implica un aumento de la productividad.

Esto permite realizar tareas tales como formación, programación y optimización de

programas sin alterar la producción. Esto añade muchas ventajas, entre ellas:

Reducción de riesgos

Arranques más rápidos

Menor tiempo para modificaciones

Aumento de la productividad

RobotStudio se basa en el controlador virtual de ABB, una copia exacta del software

real que emplean los robots en la producción. Ello permite ejecutar simulaciones muy

realistas, utilizando programas de robots reales y archivos de configuración idénticos a los

que se emplean en la fábrica.




109

Figura 49 Software ABB RobotStudio


Importación de CAD desde los principales formatos como IGES, STEP, VRML,

VDAFS, ACIS y CATIA. Esto permite trabajar con modelos generados con gran

precisión.

AutoPath es una función que permite al importar una pieza CAD, que se calcule de

manera totalmente automatizada y en poco tiempo la trayectoria que debe seguir la

herramienta del robot para seguir la curva de la pieza.

AutoReach analiza automáticamente las posibilidades de alcance. Esto permite

verificar y optimizar la disposición de la célula de trabajo en cuestión de minutos.

Optimización de trayectorias. RobotStudio puede detectar automáticamente los

programas que contengan movimientos demasiado cercanos a las singularidades y

advertir automáticamente de estos problemas, para que sea posible tomar medidas para

evitar estas situaciones. Es posible optimizar la velocidad, la aceleración, la

singularidad o los ejes para mejorar los tiempos de ciclo.

Detección de colisiones.




110

Unidad de programación virtual. Se trata de una representación gráfica de la unidad de

programación táctil real, pero controlada por desde el PC. Permite llevar a cabo todo lo

que puede hacerse en la unidad de programación táctil real, lo que hace de esta

herramienta el medio ideal para labores de enseñanza y prácticas.

Carga y descarga reales de los programas al sistema real sin necesidad de ninguna

conversión.

MultiMove. Es posible ejecutar varios robots virtuales a la vez y se incorpora la

compatibilidad con MultiMove, la nueva tecnología de IRC5 para la ejecución de

varios robots desde un mismo controlador.

Incluye un editor de modelos 3D.

Permite incorporar otros elementos a la escena como sensores y cintas transportadoras

y definir mecanismos.

Dispone de un editor de programación en leguaje RAPID.

Puede crear Tablas de Eventos, una herramienta ideal para verificar la estructura del

programa y su lógica. Cuando se ejecuta el programa, se pueden visualizar los estados

de las E/S de su célula de trabajo. Las E/S se pueden conectar a los eventos de

simulación permitiendo la simulación del robot y de todo el equipamiento de la célula

de trabajo. Es una herramienta muy interesante para los trabajos de depuración.

Este software incorpora otras herramientas que permiten la simulación de tareas

específicas como trabajo con plegadoras, pintado de superficies, soldadura por arco y

por puntos y trabajo en alta precisión.

Visual Basic for Applications (VBA) hace posible adaptar y ampliar la funcionalidad

RobotStudio. VBA permite la creación de plugins, macros o interfaces de usuario

personalizados para adaptarse a las necesidades del usuario.

Tiene una interfaz de usuario bien estructurada y clara.

Permite trabajar con diferentes sistemas de coordenadas.

Incorpora la mayor parte de los robots ABB existentes en el mercado.

3.1.2 FANUC Robotic’s ROBOGUIDE

El software Roboguide es una herramienta de animación específicamente desarrollada

para la producción y mantenimiento de sistemas de Robots. Puede ser utilizado tanto en la

oficina como en la fábrica. Esto permite una verificación rápida y de bajo coste de los

sistemas de aplicaciones robóticas.




111

Con este software es sencillo diseñar dispositivos y máquinas para su posterior

simulación.

Las aplicaciones específicas permiten trabajar de forma muy eficiente en las tareas para

las que han sido diseñadas.

Figura 50 SoftwareFANUC RoboGuide


Calibrado de célula y marco de usuario. Crea automáticamente programas de referencia

para calibrar la simulación según el sistema de robot real. Tres posiciones del robot

dadas permiten ajustar el proceso entero.

Detección de colisiones. La característica de detección de colisión da una advertencia

visual en caso de colisiones durante la simulación del robot.

Posee diversos software de aplicaciones específicas que pueden ser configuradas y

activadas de forma independiente. (Existen aplicaciones de soldadura por arco, de

soldadura por puntos, de sellado, de manipulación y ensamblaje, de encolado y de

pintura.)

Incluye un potente software de programación offline de fácil uso e intuitivo.




112

o El diseño de la célula y el tiempo de ciclo se pueden testear offline.

o Tecnología de controlador virtual para alcances y tiempos de ciclo reales.

o Todos los modelos de robots (R-J3iB) pueden simularse.

o Fácil de utilizar con Virtual Teach Pendant (menús y pantallas iguales a las del

robot real).

o La programación offline agiliza la integración del sistema y reduce costes.

o Analizador de tiempos de ciclo; detección de colisión y visualización del entorno

de trabajo.

o Visualización del trazado como Node Map; salida de vídeo AVI.

o Importación de piezas de trabajo, herramientas, accesorios y obstáculos en formato

de IGES.

Visualización gráfica y video de los programas del robot

o Trazado del movimiento mostrado durante la prueba.

o Posible salida de archivo de vídeo AVI.

o Salida gráfica de los resultados para rápida documentación y toma de decisiones.

Importación de datos CAD en formato IGES. Los formatos importados ayudan a

construir el diseño del sistema y a evaluar las operaciones del sistema rápida y

exhaustivamente.

Cuenta con un analizador de programas de Teach Pendant para analizar el tiempo de

cada línea de programa con el fin de lograr los mejores tiempos de ciclo.

Unidad de aprendizaje virtual, fácil de utilizar y con menús y pantallas iguales a las del

robot real. Fácil de utilizar, no es necesario una formación especial.

Incluye una herramienta de visión por ordenador, la cual permite simular una cámara

acoplada al extremo del robot y ofrece opciones de aprendizaje y detección de objetos a

través de los elementos virtuales de la simulación.

Otra herramienta existente permite la transformación del código ASCII de los

programas a binario para el controlador real. También es posible el caso inverso, es

decir, la interpretación de los ficheros binarios del controlador y su conversión a texto

ASCII.

Generación de programas de forma automática a partir de datos proporcionados para

seguimiento de formas geométricas.

Simulación de alta precisión de todos los comandos de los robots FANUC soportados.




113

3.1.3 KUKA Sim Pro

KUKA Sim Pro es un programa que permite elaborar diseños en 3D de instalaciones

equipadas con robots de KUKA. Con él se puede simular y examinar sin esfuerzo cualquier

diseño y concepto. Idóneo para ingenieros o integradores de sistemas.

Figura 51


Modularidad

o Dispone de una amplia biblioteca de componentes adjunta y también permite

descargar modelos de internet con ayuda del catálogo web.

o La biblioteca incluye una amplia gama de componentes eficientes que no son sólo

geométricos, sino que además tienen en parte una estructura paramétrica y cuentan

con un comportamiento que puede aplicarse directamente en la simulación (p. ej.

cintas transportadoras, barreras luminosas, etc.). Este principio modular evita que

los componentes tengan que ser dibujados de nuevo y supone por lo tanto un

ahorro considerable de tiempo.

o Los componentes eficientes disponen de puntos "magnéticos" mediante los que

pueden unirse fácilmente a otros componentes. Los componentes pueden

combinarse también con señales digitales de entrada y salida de KUKA OfficeLite

para poder, por ejemplo, controlar la garra o evaluar las señales del sensor del

componente. Las líneas transportadoras del tipo empuje-tracción y las líneas




114

transportadoras con velocidad constante también pueden ser simuladas en KUKA

Sim Pro.

o KUKA Sim Pro dispone, además, de un lenguaje abierto para crear archivos de

órdenes, Python 2.6, con el que puede ampliarse el comportamiento de los

componentes de forma flexible.

o Es posible crear y guardar bibliotecas de componentes propias para productos

propios; de este modo se pueden integrar dichos componentes en otros conceptos

de instalación en cualquier momento y presentarlos a los clientes.

o Los formatos CAD estándar que pueden importarse son: STL (Binario/ASCII),

3DS, VRML1, Robface y Google Sketchup.

o KUKA Sim Pro dispone de una amplia gama de funciones API y COM con las que

se pueden programar y utilizar Plug-Ins propios para KUKA Sim Pro.

Simulación

o Es posible utilizar las funciones de KUKA Sim Pro y KUKA OfficeLite para crear

un programa de robot KRL.

o En combinación con KUKA OfficeLite puede crear análisis de tiempos de ciclo en

tiempo real y con alta precisión con el fin de verificar el concepto de la instalación.

o Dispone de una amplia gama de funciones para diseñar la instalación.

o Permite comprobar si la simulación puede provocar colisiones.

Ficheros CAD

o Con KUKA. Sim Pro pueden importarse los siguientes ficheros CAD opcionales:

CATIA V5, CATIA V4, Siemens NX, JT, STEP, Parasolid, ProE, SolidWorks,

ACIS, IDEAS, IGES.

Comunicación

o Una vez elaborado el diseño, es posible crear un fichero PDF 3D con el software

KUKA Sim. Los ficheros PDF 3D pueden abrirse y visualizarse con Adobe

Acrobat Reader. El proceso creado en la célula de trabajo se muestra en el PDF en

forma de animación tridimensional. El complemento perfecto para poner los

resultados de su simulación a disposición de sus clientes.

3.1.4 Microsoft Robotics Studio (MRS)

Se trata de un entorno de programación relacionado con el campo de la robótica. Su

principal objetivo es acercar de una manera próxima y amigable el mundo de la robótica a




115

cualquier usuario que tenga ciertas nociones de programación. La primera versión apareció en

diciembre del año 2006.

Es un software que presenta gran compatibilidad con todos los kits de desarrollo que

existen en el mercado, intentando presentarse como el entorno de programación común entre

los diversos kits de desarrollo.

MRS permite a los desarrolladores generar servicios modulares para hardware y

software, haciendo posible que los usuarios interactúen con los robots diseñados a través de

las plataformas Windows o Web. Esto también hace posible que se puedan simular las

aplicaciones sin la necesidad de disponer del soporte hardware final.

Uno de los puntos destacados es que gracias a la utilización de una biblioteca, basada en

.NET, se consigue que el desarrollo de aplicaciones asíncronas sea algo sencillo. También hay

que remarcar, la arquitectura orientada a servicios y basada en mensajes, que facilita en gran

medida el acceso al estado de los sensores y actuadores del robot tanto a través de un

navegador Web como a través de la programación. Esto se consigue debido a que el entorno

está compuesto de modelos que permiten construir funciones de alto nivel usando

componentes sencillos y facilitando la reutilización del código de los módulos, la calidad y la

sencilla sustitución del mismo.

Figura 52

La gran diferencia entre Robotics Studio de otros entornos de programación, es la

facilidad que supone realizar un proyecto, ya que nos podemos olvidar de las largas líneas de

código y utilizar un entorno visual basado en “cajas y flechas” que resulta muy intuitivo.

Se trata de un entorno escalable y extensible ya que el modelo de programación puede

ser aplicado para una gran variedad de robots, permitiendo a los usuarios transferir lo




116

aprendido e intercambiarlo entre los diferentes robots con distinto hardware. También

permite extender la funcionalidad de la plataforma mediante bibliotecas y servicios

adicionales con lo que la ejecución en escenarios puede ser desarrollada usando diferentes

lenguajes de programación como C#, VB.NET y Python.


Programación de aplicaciones de simulación mediante lenguaje de alto nivel o con un

método visual (Microsoft Visual Programming Language).

Licencia gratuita aunque el código no es libre.

Fácilmente extensible mediante bibliotecas y servicios adicionales.

Se basa en bloques de actividades básicas y servicios interconectados a través de

conexiones que transmiten la información que se indique.

Cada actividad dispone de una serie de eventos posibles.

Es posible realizar cálculos físicos con la tarjeta AGEIA™ PhysX™ Technology. Es

posible simular en tiempo real o a intervalos, para PC’s poco potentes sin tarjeta

aceleradora de físicas.

El renderizado 3D utiliza XNA, que implementa DirectX. XNA es una API para el

desarrollo de videojuegos para PC.

Controla dispositivos de entrada, como son webcam, teclado, controles xbox entre

otros.

Tiene un editor para modelar objetos del mundo real, y depurarlos.

Permite importar recreaciones 3D de programas destinados al diseño.

Entorno grafico interactivo y accesible de alto nivel.

Las plataformas hardware utilizadas a la hora de implementar los diseños desarrollados

en MRDS permite al programador manejar un mismo lenguaje en todo momento es por

esto que estas se hacen mucho más rápidas, eficaces y menos complejas.

Microsoft Robotics también permite la creación de proyectos con hardware no

existente en sus librerías, permitiendo al usuario manjar los dispositivos electrónicos y

estructura robótica deseada, con la condición que todo será creado desde cero mediante

otras herramientas extras como: AGEIA PhysX engine (Simulación de interfaces

físicas), Microsoft DirectX (API para acceso a gráficos), Framework Microsoft XNA

(Interfaz Gráfica).




117

3.2 APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN

EDUCATIVAS EXISTENTES

3.2.1 RoboAnalyzer

3.2.2 RoboUALab

118

4. ANEXO IV – CÓDIGO DE LA APLICACIÓN

MAIN.CPP

#ifndef VENTANAPRINCIPAL_H

#define VENTANAPRINCIPAL_H

// CABECERAS

//---------------------------------------------------------------------

#include <QtGui/QMainWindow>

#include <QtGui/QMenu>

#include <QtGui/QAction>

#include <QtGui/QKeySequence>

#include "ui_ventanaPrincipal.h"

#include "qosgwidget.h" //clase de visor 3D

namespace Ui {

class ventanaPrincipal;

}

// DECLARACION DE CLASE ventanaPrincipal

//---------------------------------------------------------------------

class ventanaPrincipal : public QMainWindow

{

Q_OBJECT

public:

explicit ventanaPrincipal(QWidget *parent = 0);

~ventanaPrincipal();

Ui::ventanaPrincipal *getUiHandler();

private:

//definiendo la interfaz de la clase como un puntero

//es posible el encapsulamiento haciendo los miembros

//de la interfaz privados y ademas permite un facil

//cambio de interfaz en caso de ser necesario

Ui::ventanaPrincipal *ui;

QAction *_accionSalir;

QAction *_accionMover;

QAction *_accionProgramar;

QMenu *_menuArchivo;

QMenu *_menuPaneles;

ViewerWidget **_visores3D;

void _crearAcciones();

void _crearMenus();

public slots:

void ocultaItems(bool);

void verPanelMover();

void verPanelPrograma();

ViewerWidget* visor3D(int fil=0, int col=0);




119

};

#endif // VENTANAPRINCIPAL_H




120

VENTANA PRINCIPAL.H



// CABECERAS

//---------------------------------------------------------------------







namespace Ui {


}


//---------------------------------------------------------------------


{

Q_OBJECT

public:




private:













void _crearMenus();

public slots:





};





121

VENTANA PRINCIPAL.CPP



// CABECERAS

//---------------------------------------------------------------------







namespace Ui {


}


//---------------------------------------------------------------------


{

Q_OBJECT

public:




private:













void _crearMenus();

public slots:





};





122

QOSGWIDGET.H

// CABECERAS

//---------------------------------------------------------------------

#include "ventanaPrincipal.h" //clase de ventana principal

#include "ventanaMensajes.h" //clase de ventana de mensajes de

depuracion

#include "panelSerie.h" //clase de panel de conexion y transmision

por el puerto serie RS232


#include "StaubliRX60.h" //clase de robot Staubli - modelo RX60

// VARIABLES GLOBALES

//---------------------------------------------------------------------

// Punteros a ventanas y sus interfaces

ventanaPrincipal *v_Principal; //para acceder a la ventana principal

Ui::ventanaPrincipal *guiMain; //para acceder a la interfaz de la

ventana principal

StaubliRX60 *robot;

// PROGRAMA PRINCIPAL

//---------------------------------------------------------------------

int main( int argc, char** argv )

{

// Crear la aplicacion principal

QApplication app(argc, argv);

// Traduccion ...?

// Reenviar los mensajes de depuracion a la ventana de clase

ventanaMensajes

qInstallMsgHandler(ventanaMensajes::AppendMsgWrapper);

// Crear la interfaz principal

v_Principal = new ventanaPrincipal;

guiMain = v_Principal->getUiHandler();

// cuando se cierran todas las ventanas se finaliza la aplicacion

app.connect(&app, SIGNAL(lastWindowClosed()), &app, SLOT(quit()));

// Crear el modelo robot Staubli RX60

ViewerWidget *visor3D_1 = new ViewerWidget();

visor3D_1 = v_Principal->visor3D(1,1);

robot = new StaubliRX60( visor3D_1 );

visor3D_1->sceneRead(robot->readRoot());

/*

ViewerWidget *visor3D_2 = new ViewerWidget();

visor3D_2 = v_Principal->visor3D(1,2);

robot = new StaubliRX60( visor3D_2 );

visor3D_2->sceneRead(robot->readRoot());

*/

// Mostrar en pantalla la ventana principal

v_Principal->showMaximized();

return app.exec();

}

123

STAUBLIRX60.H

#ifndef STAUBLIRX60_H

#define STAUBLIRX60_H

#include <QtCore/QObject>

#include <QtCore/QSignalMapper>

#include <osgDB/ReadFile>

#include <osg/MatrixTransform>

#include <osg/ShapeDrawable>

#include "ventanaPrincipal.h"


#include "qosgwidget.h"

class StaubliRX60 : public QObject

{

Q_OBJECT

public:

StaubliRX60(ViewerWidget *viewWidget);

osg::ref_ptr<osg::Group> readRoot() { return this->root; }

void createScene();

void coordenadas_extremo();

void cinemDirecta();

void createAxis(osg::Transform* previousJoint,double height =

1.20,double radius = .05);

private:

//TIPO DE CONFIGURACIÓN

bool brazoIzq; // true: Brazo Izquierdo, false: Brazo

Derecho

bool codoAbajo; // true: Codo Abajo, false: Codo

Arriba

bool wrist;

//Angulos de rotacion en grados

float angulo1, angulo2, angulo3, angulo4, angulo5, angulo6;

//Limtes de los angulos de rotacion

float ang1max, ang2max, ang3max, ang4max, ang5max, ang6max;

float ang1min, ang2min, ang3min, ang4min, ang5min, ang6min;

//Velocidad de giro de todos los angulos al mismo tiempo

float vel;

//Distancias de elemntos del robot

float d1, d2, d4, d6, a2;

124

//Vectores unitarios

osg::Vec3f vecUnit_i;

osg::Vec3f vecUnit_j;

osg::Vec3f vecUnit_k;

//Matriz de estado actual del extremo: posicion + orientacion

osg::Matrixf MActualState;

//Puntero a la interfaz principal

ventanaPrincipal *appGui;

//REPRESENTACION 3D

//---------------------------------------

//Puntero al visor OSG

ViewerWidget *vOSG;

//Nodo raiz de la escena

osg::ref_ptr<osg::Group> root;

//Punteros a las piezas modelo del robot

osg::ref_ptr<osg::Node> model_base; //punteros a los modelos de

piezas del robot

osg::ref_ptr<osg::Node> model_hombro;

osg::ref_ptr<osg::Node> model_brazo;

osg::ref_ptr<osg::Node> model_codo;

osg::ref_ptr<osg::Node> model_antebrazo;

osg::ref_ptr<osg::Node> model_eje5;

osg::ref_ptr<osg::Node> model_eje6;

//Uniones entre eslabones

osg::ref_ptr<osg::MatrixTransform> joint1;






osg::ref_ptr<osg::Geode> center6;

//Ejes

QSignalMapper *signalMapper;

osg::MatrixTransform* jAxis0;







//Punto que indica la posicion a alcanzar por el extremo final

osg::MatrixTransform* MTdestino;

osg::ref_ptr<osg::Geode> destino;

osg::ref_ptr<osg::ShapeDrawable> shapeDestino;

osg::ref_ptr<osg::Box> puntoDestino;

//Punto que indica la posicion a alcanzar por la muñeca

125

osg::MatrixTransform* MTWrist;

osg::ref_ptr<osg::Geode> Wrist;

osg::ref_ptr<osg::ShapeDrawable> shapeWrist;

osg::ref_ptr<osg::Box> puntoWrist;

//---------------------------------------

public slots:

void changeAngle1_actual();






void GBox_accion();

void animar();

void animacion();

void habilitar_botones();

void actualizarMinMax();

void velChanged(int incAngle) {vel = incAngle / 10.0;}

void resetPosicion();

void cinemInversa();

void changeBrazoIzq(int);

void changeCodoAbajo(int);

void changeWrist(int);

void visibleAxis(int);

signals:

void value1Changed(QString str_ang1);

};

#endif // STAUBLIRX60_H

126

STAUBLIRX60.CPP

#include "StaubliRX60.h"

#include <QString>

//#include "StaubliRX60_cinemInversa.cpp" //Debido a su longitud

esta en otro archivo cpp

extern ventanaPrincipal *v_Principal;

extern Ui::ventanaPrincipal *guiMain;

static int nrbton = 0;

osg::TessellationHints* hints = new osg::TessellationHints;

StaubliRX60::StaubliRX60(ViewerWidget *viewWidget)

{

//Tipo de Configuracion del brazo robot

brazoIzq = true;

codoAbajo = true;

wrist = true;

connect( guiMain->checkBox_BrazoIzq, SIGNAL(stateChanged(int)), this,

SLOT(changeBrazoIzq(int)) );

connect( guiMain->checkBox_CodoAbajo, SIGNAL(stateChanged(int)), this,

SLOT(changeCodoAbajo(int)) );

connect( guiMain->checkBox_Wrist, SIGNAL(stateChanged(int)), this,

SLOT(changeWrist(int)) );


vecUnit_i = osg::Vec3f( 1.0f, 0.0f, 0.0f ); //otra forma de

inicializar

//vecUnit_i.set( 1.0f, 0.0f, 0.0f );

vecUnit_j.set( 0.0f, 1.0f, 0.0f );

vecUnit_k.set( 0.0f, 0.0f, 1.0f );

//Distancias especificas del Staubli RX60 para el modelo cinemtaico

tomado

d1 = 3.41f;

a2 = 2.90f;

d2 = 0.49f;

d4 = 3.10f;

d6 = 0.65f;

//Se guardan los punteros a la aplicacion y al visor que mostraran el

robot

//appGui = app;

vOSG = viewWidget;

//Inicializamos angulos de rotacion en grados (luego se calcula en

radianes)




127

angulo1 = 0.0; ang1max = 160.0; ang1min = -160.0;






/*







*/

//guiMain->DSpinBox1_actual->setMaximum(ang1max);

guiMain->DSpinBox1_actual->setMaximum(ang1max);






guiMain->DSpinBox1_actual->setMinimum(ang1min);






//Inicilizacion limites de angulos

guiMain->DSpinBox1_min->setValue(ang1min);






guiMain->DSpinBox1_max->setValue(ang1max);






vel = 0.0;

//-----------------------------------------------------------------

---

//Cargamos los modelos en los nodos manejados por punteros

model_base = osgDB::readNodeFile("./Models/base.obj" );

model_hombro = osgDB::readNodeFile("./Models/hombro.obj" );

model_brazo = osgDB::readNodeFile("./Models/brazo.obj" );

model_codo = osgDB::readNodeFile("./Models/codo.obj" );

model_antebrazo = osgDB::readNodeFile("./Models/antebrazo.obj" );

model_eje5 = osgDB::readNodeFile("./Models/eje5.obj" );




128


//-----------------------------------------------------------------

---

this->createScene();

//COORDENADAS DEL EXTREMO

this->coordenadas_extremo();

this->cinemDirecta();

//Acciones del GroupBox

connect( guiMain->act_animacion, SIGNAL(clicked()), this,

SLOT(GBox_accion()) );

connect(guiMain->act_botones, SIGNAL(clicked()), this,


//Inicilaizacion de valores de la interfaz

//guiMain->act_botones->setChecked(true); YA hecho desde QtDesigner

guiMain->label_1actual->setText("0.00");

habilitar_botones();

connect( this, SIGNAL(value1Changed(QString)), guiMain->label_1actual,

SLOT(setText(QString)) );

//Conexiones para modificar los valores max y min de los angulos desde

la interfaz

connect( guiMain->DSpinBox1_min, SIGNAL(valueChanged(double)), this,

SLOT(actualizarMinMax()) );

connect( guiMain->DSpinBox1_max, SIGNAL(valueChanged(double)), this,






















//Conexiones de la Cinematica Inversa

connect( guiMain->DSpinBox_goX, SIGNAL(valueChanged(double)), this,

SLOT(cinemInversa()) );

connect( guiMain->DSpinBox_goY, SIGNAL(valueChanged(double)), this,


129

connect( guiMain->DSpinBox_goZ, SIGNAL(valueChanged(double)), this,


connect( guiMain->DSpinBox_goALFA, SIGNAL(valueChanged(double)), this,


connect( guiMain->DSpinBox_goBETA, SIGNAL(valueChanged(double)), this,


connect( guiMain->DSpinBox_goGAMMA, SIGNAL(valueChanged(double)), this,


//Desactivar los ejes de la vista

signalMapper = new QSignalMapper(this);

signalMapper->setMapping(guiMain->checkBox_Eje0, 0);







connect( guiMain->checkBox_Eje0, SIGNAL(stateChanged(int)),

signalMapper, SLOT (map()) );













connect(signalMapper, SIGNAL(mapped(int)), this,

SLOT(visibleAxis(int)));

}

void StaubliRX60::createScene()

{

//Las coordenadas globales en OSG creo que corresponden con

//la del sistema de referencia xyz0

//Creamos un nuevo nodo raiz de la escena

this->root = new osg::Group;

//Se representan las piezas y los puntos de union

//Algunas distancias de ptos de union no corresponden con ninguna del

modelo cinematico, otras sí

//Los ptos de union se usan para rotar las articulaciones sobre ellos

osg::ref_ptr<osg::Geode> center0 = new osg::Geode;

osg::ref_ptr<osg::ShapeDrawable> j0 = new osg::ShapeDrawable;

j0->setShape( new osg::Sphere(osg::Vec3(0.0f, 0.0f, 0.0f),0.1f) );

j0->setColor( osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f) );

center0->addDrawable(j0);

130























//osg::ref_ptr<osg::Geode> center6 = new osg::Geode;

center6 = new osg::Geode;





//Las uniones joint corresponden con los puntos reales

//de giro, es decir, los centros marcados con puntos rojos

//La j0 es el origen

//

//Referidos todos los giros de forma relativa

//girar sobre z siempre es girar sobre la longitudinal

//de cada pieza, etc

joint1 = new osg::MatrixTransform;

osg::Matrix z1trans = osg::Matrix::translate( 0.0f, 0.0f, 0.0f );

osg::Matrix z1rot = osg::Matrix::rotate( angulo1, 0.0f, 0.0f, 1.0f );

//usar inDegrees(angulo1) para evitara convertir luego a grados manualmente

joint1->setMatrix( z1trans * z1rot );


osg::Matrix yz2trans = osg::Matrix::translate( 0.975f, 0.0f, 3.41f );

osg::Matrix menos_yz2trans = osg::Matrix::translate( -0.975f, 0.0f, -

3.41f );

osg::Matrix y2rot = osg::Matrix::rotate( angulo2, 1.0f, 0.0f, 0.0f );

joint2->setMatrix( menos_yz2trans * y2rot * yz2trans );




6.31f );




131




7.41f );


joint4->setMatrix( menos_yz4trans * z4rot * yz4trans );




9.41f );






10.06f );



root->addChild ( center0 );

root->addChild ( model_base );

root->addChild ( joint1 );

joint1->addChild ( center1 );

joint1->addChild ( model_hombro );

joint1->addChild ( joint2 );


joint2->addChild ( model_brazo );



joint3->addChild ( model_codo );



joint4->addChild ( model_antebrazo );



joint5->addChild ( model_eje5 );




//-------------------------------------------------------------------------

------

//------------------------------------------ EJES -------------------------

------

//eje0 fijo de referencia

jAxis0 = new osg::MatrixTransform;

root->addChild( jAxis0 );




132


osg::Matrix transAxis1 = osg::Matrix::translate( 0.0f, 0.0f, 3.41f );

osg::Matrix rotAxis1y = osg::Matrix::rotate( osg::PI_2, 0.0f, 1.0f,

0.0f );

osg::Matrix rotAxis1z = osg::Matrix::rotate( -osg::PI_2, 0.0f, 0.0f,

1.0f );

jAxis1->setMatrix( rotAxis1z * rotAxis1y * transAxis1 ); //primero

gira en y, luego en z, aqui se multiplica al reves

joint1->addChild( jAxis1 );




0.0f );

osg::Matrix rotAxis2z = osg::Matrix::rotate( osg::PI, 0.0f, 0.0f, 1.0f

);

jAxis2->setMatrix( rotAxis2z * rotAxis2y * transAxis2 );





1.0f );

jAxis3->setMatrix( rotAxis3z * transAxis3 );





0.0f );


1.0f );






1.0f );






1.0f );



this->createAxis(jAxis0); //ejes







//this->createAxis(joint2);//borrarrrrrrrrrrrrrrrrrrrrrrrrrrrrrr




133

//Punto destino

MTdestino = new osg::MatrixTransform();

destino = new osg::Geode;

shapeDestino = new osg::ShapeDrawable;

puntoDestino = new osg::Box(osg::Vec3(0.0f, 0.0f, 0.0f),0.1f);

shapeDestino->setColor( osg::Vec4(1.0f, 0.0f, 1.0f, 1.0f) );

shapeDestino->setShape(puntoDestino);

destino->addDrawable(shapeDestino);

MTdestino->addChild(destino);

root->addChild (MTdestino);

this->createAxis(MTdestino,0.4,0.01);

//Punto muñeca

MTWrist = new osg::MatrixTransform();

Wrist = new osg::Geode;

shapeWrist = new osg::ShapeDrawable;

puntoWrist = new osg::Box(osg::Vec3(0.0f, 0.0f, 0.0f),0.1f);

shapeWrist->setColor( osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f) );

shapeWrist->setShape(puntoWrist);

Wrist->addDrawable(shapeWrist);

MTWrist->addChild(Wrist);

root->addChild (MTWrist);

this->createAxis(MTWrist,0.4,0.01);

}

void StaubliRX60::changeAngle1_actual()

{

angulo1 = guiMain->DSpinBox1_actual->value();


osg::Matrix z1rot = osg::Matrix::rotate(

osg::DegreesToRadians(angulo1), 0.0f, 0.0f, 1.0f );




}


{




3.41f );

osg::Matrix y2rot = osg::Matrix::rotate(





}




134


{




6.31f );






}


{




7.41f );






}


{




9.41f );






}


{




10.06f );






}




135

void StaubliRX60::coordenadas_extremo()

{

//ejecutar esto al principio

float extremoX , extremoY , extremoZ;

/* //hacer esto como funcion actualizar coordenadas

osg::Matrix j1 = joint1->getMatrix();






osg::Matrix transformTotal = j1 * j2 * j3 * j4 * j5 * j6;

*/

//Mediante este metodo de OSG se puede obtener las coordenadas del

punto extremo

osg::Vec3 posExtremo = center6->getBound().center() *

osg::computeLocalToWorld(center6->getParentalNodePaths()[0]);

extremoX = posExtremo.x();

extremoY = posExtremo.y();

extremoZ = posExtremo.z();

//----------------------------

guiMain->lineEdit_extrX->setText( QString::number(extremoX, 'f', 2) );

guiMain->lineEdit_extrY->setText( QString::number(extremoY, 'f', 2) );

guiMain->lineEdit_extrZ->setText( QString::number(extremoZ, 'f', 2) );

}

void StaubliRX60::GBox_accion()

{

if ( guiMain->act_botones->isChecked() && nrbton!=0 )

{


nrbton = 0;

return;

}

if ( guiMain->act_animacion->isChecked() && nrbton!=1 )

{

animar();

nrbton = 1;

return;

}

}

void StaubliRX60::animar()

{

guiMain->DSpinBox1_actual->disconnect();









136

guiMain->btn_home->disconnect();

guiMain->btn_situar->disconnect();

/**Hasta que no se ha pulsado el check de Animar y haya un cambio en la

el slider de velocidad

/* no comienza la animacion, debido a que hasta que esta animar() no se

leen sus cambios

/* Se podria deshabilitar la barra pero para ello es necesario realizar

un control desde la mainwindow

/* ya que es una cualidad protected. MODIFICAR A CONTROL DE ELEMENTOS

DE LA INTERFAZ DESDE LA MAINWINDOW

**/

connect( &vOSG->_timer, SIGNAL(timeout()), this, SLOT(animacion()) );

connect( guiMain->hSlider, SIGNAL(valueChanged(int)), this,

SLOT(velChanged(int)) );

velChanged( guiMain->hSlider->value() ); //Por si la barra no parte de

cero al seleccionar animacion

}

void StaubliRX60::animacion()

{

if (angulo1 >= 360) { angulo1 = angulo1 - 360; }

this->angulo1 += vel;

QString str_ang1 = QString::number(angulo1, 'f', 2);

emit value1Changed(str_ang1); //se emite una señal que indica que el

angulo1 ha cambiado de valor





if (angulo2 == 360) { angulo2 = 0; }

this->angulo2 += vel;;



3.41f );




if (angulo3 == 360) { angulo3 = 0; }




6.31f );




if (angulo4 == 360) { angulo4 = 0; }




7.41f );




137




if (angulo5 == 360) { angulo5 = 0; }




9.41f );




if (angulo6 == 360) { angulo6 = 0; }




10.06f );






}

void StaubliRX60::habilitar_botones()

{

vOSG->_timer.disconnect(this); //detiene la animacion

v_Principal->disconnect();

//Se emiten señales cuando cambian los valores de los SpinBox o cuando

se pulsa Enter

QObject::connect( guiMain->DSpinBox1_actual,

SIGNAL(valueChanged(double)), this,

SLOT(changeAngle1_actual()));
















QObject::connect( guiMain->DSpinBox1_actual, SIGNAL(editingFinished()),

this,



this,





138


this,



this,



this,



this,


//Para mostrar valor en label azul

connect( guiMain->DSpinBox1_actual, SIGNAL(valueChanged(QString)),

this,

SIGNAL(value1Changed(QString)) ); //se emite una señal que indica

que el spinbox1 ha cambiado de valor

connect( guiMain->btn_home, SIGNAL(clicked()), this,

SLOT(resetPosicion()) );

connect( guiMain->btn_situar, SIGNAL(clicked()), this,


}

void StaubliRX60::actualizarMinMax()

{

guiMain->DSpinBox1_actual->setMinimum( guiMain->DSpinBox1_min->value()

);


);


);


);


);


);

guiMain->DSpinBox1_actual->setMaximum( guiMain->DSpinBox1_max->value()

);


);


);


);


);


);

}

void StaubliRX60::resetPosicion()

{

//angulo1, angulo2, angulo3, angulo4, angulo5, angulo6 = 0.0;

guiMain->DSpinBox1_actual->setValue(0.0);




139






changeAngle1_actual();






}

void StaubliRX60::cinemDirecta()

{

float ang1 = osg::DegreesToRadians( angulo1 );






//Hay que escribir las matrices por columnas en lugar de por filas, es

decir,

//como si fueran las traspuestas para que los calclculos en C++ y OSG

sean correctos

osg::Matrixf A01 ( sin(ang1), -cos(ang1), 0.0f, 0.0f,

0.0f, 0.0f, -1.0f,

0.0f,

cos(ang1), sin(ang1), 0.0f, 0.0f,

0.0f, 0.0f, d1, 1.0f

);

osg::Matrixf A12 ( sin(ang2), -cos(ang2), 0.0f,

0.0f,

cos(ang2), sin(ang2), 0.0f,

0.0f,

0.0f, 0.0f, 1.0f,

0.0f,

a2*sin(ang2), -a2*cos(ang2), d2, 1.0f

);

osg::Matrixf A23 ( -sin(ang3), cos(ang3), 0.0f, 0.0f,

0.0f, 0.0f, 1.0f, 0.0f,


0.0f, 0.0f, 0.0f, 1.0f );

osg::Matrixf A34 ( cos(ang4), sin(ang4), 0.0f, 0.0f,

0.0f, 0.0f, -1.0f, 0.0f,

-sin(ang4), cos(ang4), 0.0f, 0.0f,

0.0f, 0.0f, d4, 1.0f );


0.0f, 0.0f, 1.0f, 0.0f,

sin(ang5), -cos(ang5), 0.0f, 0.0f,




140

0.0f, 0.0f, 0.0f, 1.0f );



0.0f, 0.0f, 1.0f, 0.0f,

0.0f, 0.0f, d6, 1.0f );

//Hay que multiplicar las matrices de forma inversa por estar

traspuestas a como deben ser

//Se han traspuesto porque OSG trabaja asi y se puede emplear si las

funciones getTrans y getRotate

osg::Matrixf A03 = A23 * A12 * A01; //Matriz de posicion

osg::Matrixf A36 = A56 * A45 * A34; //Matriz de orientacion

osg::Matrixf A06 = A36 * A03; //Matriz de referencia del extremo

final (C6) a la ref 0 (C1)

float posX = A06.getTrans().x();

float posY = A06.getTrans().y();

float posZ = A06.getTrans().z();

guiMain->lineEdit_extrX_2->setText( QString::number(posX, 'f', 2) );

guiMain->lineEdit_extrY_2->setText( QString::number(posY, 'f', 2) );

guiMain->lineEdit_extrZ_2->setText( QString::number(posZ, 'f', 2) );

MActualState = A06;

}

void StaubliRX60::changeBrazoIzq(int state)

{

brazoIzq = state;

}

void StaubliRX60::changeCodoAbajo(int state)

{

codoAbajo = state;

}

void StaubliRX60::changeWrist(int state)

{

wrist = state;

}

void StaubliRX60::createAxis(osg::Transform* previousJoint, double height,

double radius)

{

osg::MatrixTransform* zmt = new osg::MatrixTransform();

previousJoint->addChild(zmt);

osg::ShapeDrawable *zShape = new osg::ShapeDrawable(new

osg::Cylinder(osg::Vec3(0.0f,0.0f,height/2),radius,height),hints);

osg::ShapeDrawable *zCone = new osg::ShapeDrawable(new

osg::Cone(osg::Vec3(0.0f,0.0f,0.0f),radius*3,0.2),hints);

osg::MatrixTransform* zmtCone = new osg::MatrixTransform();

osg::Geode *zgCone = new osg::Geode;

zmtCone->setMatrix( osg::Matrix::translate(0.0,0.0,height));




141

zShape->setColor(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f));

zCone->setColor(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f));

osg::Geode *z = new osg::Geode;

z->addDrawable(zShape);

zgCone->addDrawable(zCone);

zmtCone->addChild(zgCone);

zmt->addChild(z);

zmt->addChild(zmtCone);

//-------------------------------------------------------------------------

--------------------------

osg::MatrixTransform* xmt = new osg::MatrixTransform();

previousJoint->addChild(xmt);

osg::Matrix xMatrix = osg::Matrix::rotate(osg::PI_2, 0.0, 1.0, 0.0);

xmt->setMatrix(xMatrix);

osg::ShapeDrawable *xShape = new osg::ShapeDrawable(new


osg::ShapeDrawable *xCone = new osg::ShapeDrawable(new


osg::MatrixTransform* xmtCone = new osg::MatrixTransform();

osg::Geode *xgCone = new osg::Geode;

xmtCone->setMatrix( osg::Matrix::translate(0.0,0.0,height));

xShape->setColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));

xCone->setColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));

osg::Geode *x = new osg::Geode;

x->addDrawable(xShape);

xgCone->addDrawable(xCone);

xmtCone->addChild(xgCone);

xmt->addChild(x);

xmt->addChild(xmtCone);

//-------------------------------------------------------------------------

--------------------------

osg::MatrixTransform *ymt = new osg::MatrixTransform();

previousJoint->addChild(ymt);

osg::Matrix yMatrix = osg::Matrix::rotate(-osg::PI_2, 1.0, 0.0, 0.0);

ymt->setMatrix(yMatrix);

osg::ShapeDrawable *yShape = new osg::ShapeDrawable(new


osg::ShapeDrawable *yCone = new osg::ShapeDrawable(new


osg::MatrixTransform* ymtCone = new osg::MatrixTransform();

osg::Geode *ygCone = new osg::Geode;

ymtCone->setMatrix( osg::Matrix::translate(0.0,0.0,height));

yShape->setColor(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f));

yCone->setColor(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f));

osg::Geode *y = new osg::Geode;

y->addDrawable(yShape);

ygCone->addDrawable(yCone);




142

ymtCone->addChild(ygCone);

ymt->addChild(y);

ymt->addChild(ymtCone);

}

void StaubliRX60::visibleAxis(int axis)

{

switch(axis)

{

case 0:

jAxis0->setNodeMask( guiMain->checkBox_Eje0->isChecked() );

break;

case 1:


//desactiva o activa vista de este eje

break;

case 2:


break;

case 3:


break;

case 4:


break;

case 5:


break;

default:


}

}

143

STAUBLIRX60_CINEMINVERSA.CPP


#include <QString>

//#include "StaubliRX60_cinemInversa.cpp" //Debido a su longitud

esta en otro archivo cpp

extern ventanaPrincipal *v_Principal;


static int nrbton = 0;

osg::TessellationHints* hints = new osg::TessellationHints;

StaubliRX60::StaubliRX60(ViewerWidget *viewWidget)

{

//Tipo de Configuracion del brazo robot

brazoIzq = true;

codoAbajo = true;

wrist = true;

connect( guiMain->checkBox_BrazoIzq, SIGNAL(stateChanged(int)), this,

SLOT(changeBrazoIzq(int)) );

connect( guiMain->checkBox_CodoAbajo, SIGNAL(stateChanged(int)), this,

SLOT(changeCodoAbajo(int)) );

connect( guiMain->checkBox_Wrist, SIGNAL(stateChanged(int)), this,

SLOT(changeWrist(int)) );


vecUnit_i = osg::Vec3f( 1.0f, 0.0f, 0.0f ); //otra forma de

inicializar

//vecUnit_i.set( 1.0f, 0.0f, 0.0f );

vecUnit_j.set( 0.0f, 1.0f, 0.0f );

vecUnit_k.set( 0.0f, 0.0f, 1.0f );

//Distancias especificas del Staubli RX60 para el modelo cinemtaico

tomado

d1 = 3.41f;

a2 = 2.90f;

d2 = 0.49f;

d4 = 3.10f;

d6 = 0.65f;

//Se guardan los punteros a la aplicacion y al visor que mostraran el

robot

//appGui = app;

vOSG = viewWidget;

//Inicializamos angulos de rotacion en grados (luego se calcula en

radianes)




144







/*







*/

//guiMain->DSpinBox1_actual->setMaximum(ang1max);













//Inicilizacion limites de angulos













vel = 0.0;

//-----------------------------------------------------------------

---

//Cargamos los modelos en los nodos manejados por punteros

model_base = osgDB::readNodeFile("./Models/base.obj" );

model_hombro = osgDB::readNodeFile("./Models/hombro.obj" );

model_brazo = osgDB::readNodeFile("./Models/brazo.obj" );

model_codo = osgDB::readNodeFile("./Models/codo.obj" );

model_antebrazo = osgDB::readNodeFile("./Models/antebrazo.obj" );





145


//-----------------------------------------------------------------

---

this->createScene();

//COORDENADAS DEL EXTREMO



//Acciones del GroupBox

connect( guiMain->act_animacion, SIGNAL(clicked()), this,


connect(guiMain->act_botones, SIGNAL(clicked()), this,


//Inicilaizacion de valores de la interfaz

//guiMain->act_botones->setChecked(true); YA hecho desde QtDesigner

guiMain->label_1actual->setText("0.00");


connect( this, SIGNAL(value1Changed(QString)), guiMain->label_1actual,

SLOT(setText(QString)) );

//Conexiones para modificar los valores max y min de los angulos desde

la interfaz

























//Conexiones de la Cinematica Inversa

connect( guiMain->DSpinBox_goX, SIGNAL(valueChanged(double)), this,


connect( guiMain->DSpinBox_goY, SIGNAL(valueChanged(double)), this,





146

connect( guiMain->DSpinBox_goZ, SIGNAL(valueChanged(double)), this,


connect( guiMain->DSpinBox_goALFA, SIGNAL(valueChanged(double)), this,


connect( guiMain->DSpinBox_goBETA, SIGNAL(valueChanged(double)), this,


connect( guiMain->DSpinBox_goGAMMA, SIGNAL(valueChanged(double)), this,


//Desactivar los ejes de la vista

signalMapper = new QSignalMapper(this);






















connect(signalMapper, SIGNAL(mapped(int)), this,

SLOT(visibleAxis(int)));

}

void StaubliRX60::createScene()

{

//Las coordenadas globales en OSG creo que corresponden con

//la del sistema de referencia xyz0

//Creamos un nuevo nodo raiz de la escena

this->root = new osg::Group;

//Se representan las piezas y los puntos de union

//Algunas distancias de ptos de union no corresponden con ninguna del

modelo cinematico, otras sí

//Los ptos de union se usan para rotar las articulaciones sobre ellos









147























//osg::ref_ptr<osg::Geode> center6 = new osg::Geode;

center6 = new osg::Geode;





//Las uniones joint corresponden con los puntos reales

//de giro, es decir, los centros marcados con puntos rojos

//La j0 es el origen

//

//Referidos todos los giros de forma relativa

//girar sobre z siempre es girar sobre la longitudinal

//de cada pieza, etc




//usar inDegrees(angulo1) para evitara convertir luego a grados manualmente





3.41f );






6.31f );




148




7.41f );






9.41f );






10.06f );



root->addChild ( center0 );

root->addChild ( model_base );

root->addChild ( joint1 );


joint1->addChild ( model_hombro );



joint2->addChild ( model_brazo );



joint3->addChild ( model_codo );



joint4->addChild ( model_antebrazo );







//-------------------------------------------------------------------------

------

//------------------------------------------ EJES -------------------------

------

//eje0 fijo de referencia


root->addChild( jAxis0 );




149




0.0f );


1.0f );

jAxis1->setMatrix( rotAxis1z * rotAxis1y * transAxis1 ); //primero

gira en y, luego en z, aqui se multiplica al reves





0.0f );

osg::Matrix rotAxis2z = osg::Matrix::rotate( osg::PI, 0.0f, 0.0f, 1.0f

);






1.0f );






0.0f );


1.0f );






1.0f );






1.0f );










//this->createAxis(joint2);//borrarrrrrrrrrrrrrrrrrrrrrrrrrrrrrr




150

//Punto destino

MTdestino = new osg::MatrixTransform();

destino = new osg::Geode;

shapeDestino = new osg::ShapeDrawable;

puntoDestino = new osg::Box(osg::Vec3(0.0f, 0.0f, 0.0f),0.1f);

shapeDestino->setColor( osg::Vec4(1.0f, 0.0f, 1.0f, 1.0f) );

shapeDestino->setShape(puntoDestino);

destino->addDrawable(shapeDestino);

MTdestino->addChild(destino);

root->addChild (MTdestino);

this->createAxis(MTdestino,0.4,0.01);

//Punto muñeca

MTWrist = new osg::MatrixTransform();

Wrist = new osg::Geode;

shapeWrist = new osg::ShapeDrawable;

puntoWrist = new osg::Box(osg::Vec3(0.0f, 0.0f, 0.0f),0.1f);

shapeWrist->setColor( osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f) );

shapeWrist->setShape(puntoWrist);

Wrist->addDrawable(shapeWrist);

MTWrist->addChild(Wrist);

root->addChild (MTWrist);

this->createAxis(MTWrist,0.4,0.01);

}


{








}


{




3.41f );






}




151


{




6.31f );






}


{




7.41f );






}


{




9.41f );






}


{




10.06f );






}




152

void StaubliRX60::coordenadas_extremo()

{

//ejecutar esto al principio

float extremoX , extremoY , extremoZ;

/* //hacer esto como funcion actualizar coordenadas







osg::Matrix transformTotal = j1 * j2 * j3 * j4 * j5 * j6;

*/

//Mediante este metodo de OSG se puede obtener las coordenadas del

punto extremo

osg::Vec3 posExtremo = center6->getBound().center() *

osg::computeLocalToWorld(center6->getParentalNodePaths()[0]);

extremoX = posExtremo.x();

extremoY = posExtremo.y();

extremoZ = posExtremo.z();

//----------------------------

guiMain->lineEdit_extrX->setText( QString::number(extremoX, 'f', 2) );

guiMain->lineEdit_extrY->setText( QString::number(extremoY, 'f', 2) );

guiMain->lineEdit_extrZ->setText( QString::number(extremoZ, 'f', 2) );

}

void StaubliRX60::GBox_accion()

{

if ( guiMain->act_botones->isChecked() && nrbton!=0 )

{


nrbton = 0;

return;

}

if ( guiMain->act_animacion->isChecked() && nrbton!=1 )

{

animar();

nrbton = 1;

return;

}

}

void StaubliRX60::animar()

{










153

guiMain->btn_home->disconnect();

guiMain->btn_situar->disconnect();

/**Hasta que no se ha pulsado el check de Animar y haya un cambio en la

el slider de velocidad

/* no comienza la animacion, debido a que hasta que esta animar() no se

leen sus cambios

/* Se podria deshabilitar la barra pero para ello es necesario realizar

un control desde la mainwindow

/* ya que es una cualidad protected. MODIFICAR A CONTROL DE ELEMENTOS

DE LA INTERFAZ DESDE LA MAINWINDOW

**/

connect( &vOSG->_timer, SIGNAL(timeout()), this, SLOT(animacion()) );

connect( guiMain->hSlider, SIGNAL(valueChanged(int)), this,

SLOT(velChanged(int)) );

velChanged( guiMain->hSlider->value() ); //Por si la barra no parte de

cero al seleccionar animacion

}

void StaubliRX60::animacion()

{

if (angulo1 >= 360) { angulo1 = angulo1 - 360; }

this->angulo1 += vel;

QString str_ang1 = QString::number(angulo1, 'f', 2);

emit value1Changed(str_ang1); //se emite una señal que indica que el

angulo1 ha cambiado de valor





if (angulo2 == 360) { angulo2 = 0; }




3.41f );




if (angulo3 == 360) { angulo3 = 0; }




6.31f );




if (angulo4 == 360) { angulo4 = 0; }




7.41f );




154




if (angulo5 == 360) { angulo5 = 0; }




9.41f );




if (angulo6 == 360) { angulo6 = 0; }




10.06f );






}

void StaubliRX60::habilitar_botones()

{

vOSG->_timer.disconnect(this); //detiene la animacion

v_Principal->disconnect();

//Se emiten señales cuando cambian los valores de los SpinBox o cuando

se pulsa Enter




















this,



this,





155


this,



this,



this,



this,


//Para mostrar valor en label azul

connect( guiMain->DSpinBox1_actual, SIGNAL(valueChanged(QString)),

this,

SIGNAL(value1Changed(QString)) ); //se emite una señal que indica

que el spinbox1 ha cambiado de valor

connect( guiMain->btn_home, SIGNAL(clicked()), this,

SLOT(resetPosicion()) );

connect( guiMain->btn_situar, SIGNAL(clicked()), this,


}

void StaubliRX60::actualizarMinMax()

{


);


);


);


);


);


);


);


);


);


);


);


);

}

void StaubliRX60::resetPosicion()

{

//angulo1, angulo2, angulo3, angulo4, angulo5, angulo6 = 0.0;





156












}

void StaubliRX60::cinemDirecta()

{







//Hay que escribir las matrices por columnas en lugar de por filas, es

decir,

//como si fueran las traspuestas para que los calclculos en C++ y OSG

sean correctos

osg::Matrixf A01 ( sin(ang1), -cos(ang1), 0.0f, 0.0f,

0.0f, 0.0f, -1.0f,

0.0f,


0.0f, 0.0f, d1, 1.0f

);

osg::Matrixf A12 ( sin(ang2), -cos(ang2), 0.0f,

0.0f,

cos(ang2), sin(ang2), 0.0f,

0.0f,

0.0f, 0.0f, 1.0f,

0.0f,

a2*sin(ang2), -a2*cos(ang2), d2, 1.0f

);

osg::Matrixf A23 ( -sin(ang3), cos(ang3), 0.0f, 0.0f,

0.0f, 0.0f, 1.0f, 0.0f,


0.0f, 0.0f, 0.0f, 1.0f );


0.0f, 0.0f, -1.0f, 0.0f,


0.0f, 0.0f, d4, 1.0f );


0.0f, 0.0f, 1.0f, 0.0f,

sin(ang5), -cos(ang5), 0.0f, 0.0f,




157

0.0f, 0.0f, 0.0f, 1.0f );



0.0f, 0.0f, 1.0f, 0.0f,

0.0f, 0.0f, d6, 1.0f );

//Hay que multiplicar las matrices de forma inversa por estar

traspuestas a como deben ser

//Se han traspuesto porque OSG trabaja asi y se puede emplear si las

funciones getTrans y getRotate

osg::Matrixf A03 = A23 * A12 * A01; //Matriz de posicion

osg::Matrixf A36 = A56 * A45 * A34; //Matriz de orientacion

osg::Matrixf A06 = A36 * A03; //Matriz de referencia del extremo

final (C6) a la ref 0 (C1)

float posX = A06.getTrans().x();

float posY = A06.getTrans().y();

float posZ = A06.getTrans().z();

guiMain->lineEdit_extrX_2->setText( QString::number(posX, 'f', 2) );

guiMain->lineEdit_extrY_2->setText( QString::number(posY, 'f', 2) );

guiMain->lineEdit_extrZ_2->setText( QString::number(posZ, 'f', 2) );

MActualState = A06;

}

void StaubliRX60::changeBrazoIzq(int state)

{

brazoIzq = state;

}

void StaubliRX60::changeCodoAbajo(int state)

{

codoAbajo = state;

}

void StaubliRX60::changeWrist(int state)

{

wrist = state;

}

void StaubliRX60::createAxis(osg::Transform* previousJoint, double height,

double radius)

{

osg::MatrixTransform* zmt = new osg::MatrixTransform();

previousJoint->addChild(zmt);

osg::ShapeDrawable *zShape = new osg::ShapeDrawable(new


osg::ShapeDrawable *zCone = new osg::ShapeDrawable(new


osg::MatrixTransform* zmtCone = new osg::MatrixTransform();

osg::Geode *zgCone = new osg::Geode;

zmtCone->setMatrix( osg::Matrix::translate(0.0,0.0,height));




158

zShape->setColor(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f));

zCone->setColor(osg::Vec4(0.0f, 0.0f, 1.0f, 1.0f));

osg::Geode *z = new osg::Geode;

z->addDrawable(zShape);

zgCone->addDrawable(zCone);

zmtCone->addChild(zgCone);

zmt->addChild(z);

zmt->addChild(zmtCone);

//-------------------------------------------------------------------------

--------------------------

osg::MatrixTransform* xmt = new osg::MatrixTransform();

previousJoint->addChild(xmt);

osg::Matrix xMatrix = osg::Matrix::rotate(osg::PI_2, 0.0, 1.0, 0.0);

xmt->setMatrix(xMatrix);

osg::ShapeDrawable *xShape = new osg::ShapeDrawable(new


osg::ShapeDrawable *xCone = new osg::ShapeDrawable(new


osg::MatrixTransform* xmtCone = new osg::MatrixTransform();

osg::Geode *xgCone = new osg::Geode;

xmtCone->setMatrix( osg::Matrix::translate(0.0,0.0,height));

xShape->setColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));

xCone->setColor(osg::Vec4(1.0f, 0.0f, 0.0f, 1.0f));

osg::Geode *x = new osg::Geode;

x->addDrawable(xShape);

xgCone->addDrawable(xCone);

xmtCone->addChild(xgCone);

xmt->addChild(x);

xmt->addChild(xmtCone);

//-------------------------------------------------------------------------

--------------------------

osg::MatrixTransform *ymt = new osg::MatrixTransform();

previousJoint->addChild(ymt);

osg::Matrix yMatrix = osg::Matrix::rotate(-osg::PI_2, 1.0, 0.0, 0.0);

ymt->setMatrix(yMatrix);

osg::ShapeDrawable *yShape = new osg::ShapeDrawable(new


osg::ShapeDrawable *yCone = new osg::ShapeDrawable(new


osg::MatrixTransform* ymtCone = new osg::MatrixTransform();

osg::Geode *ygCone = new osg::Geode;

ymtCone->setMatrix( osg::Matrix::translate(0.0,0.0,height));

yShape->setColor(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f));

yCone->setColor(osg::Vec4(0.0f, 1.0f, 0.0f, 1.0f));

osg::Geode *y = new osg::Geode;

y->addDrawable(yShape);

ygCone->addDrawable(yCone);




159

ymtCone->addChild(ygCone);

ymt->addChild(y);

ymt->addChild(ymtCone);

}

void StaubliRX60::visibleAxis(int axis)

{

switch(axis)

{

case 0:


break;

case 1:


//desactiva o activa vista de este eje

break;

case 2:


break;

case 3:


break;

case 4:


break;

case 5:


break;

default:


}

}

160

PUERTOSERIE.H

/* qesptest.h

**************************************/

#ifndef _panelSerie_H_

#define _panelSerie_H_

#include "QtExtSerialPort/qextserialport.h"

#include "QtExtSerialPort/qextserialenumerator.h"

#include <QtGui/QWidget>

#include <QtGui>

#include "InterpreteComandos.h"

class QLineEdit;

class QTextEdit;

class QextSerialPort;

class QSpinBox;

class panelSerie : public QWidget

{

Q_OBJECT

public:

panelSerie(QWidget *parent=0);

virtual ~panelSerie();

//private:

public:

QTimer *timeout; //Permite controlar el tiempo de respuesta a un

comando por puerto serie

QextSerialPort *port;

QStringList *portList;

QLabel *stateCOM;

QLineEdit *message;

QTextEdit *sent_msg;

QTextEdit *received_msg;

//QSpinBox *delaySpinBox;

QComboBox *selectPort;

QPushButton *actCOMButton;

QPushButton *addCOMButton;

QPushButton *configCOMButton;

QPushButton *CRButton;

QPushButton *LFButton;

QPushButton *transmitButton;

QPushButton *receiveButton;

QPushButton *commandButton;

QPushButton *openButton;

QPushButton *closeButton;

int baud, bits, par, stop, flow; //datos almacenados del puerto actual

//Pero PUEDE haber VARIOS -->???

161

//Habra que usar memoria dinamica, o usar una nueva clase puerto

char buffLectura[1024];

QString sigComando;

//InterpreteComandos interprete;

signals:

void comandoCompleto();

//private slots:

public slots:

void transmitMsg();

void receiveMsg();

void commandMsg();

void appendCR(); // inserta CR en la linea de texto de entrada

void appendCRcad( QString &cadena ); // inserta CR a una cadena de

texto

void appendLF();

void appendLFcad( QString &cadena );

void closePort();

void openPort();

//public

void detectCOMPorts();

void defaultConfigCOM(QString);

void EnablePort();

void showConfigCOMDialog();

void showAddCOMDialog();

void addCOMPort(QString);

void configCOMPort(QList<int>);

void handleSerialData();

void reportWritten(qint64);

void closedAddCOMDialog();

void closedConfigCOMDialog();

bool eventFilter(QObject *object, QEvent *event);

};

#endif

162

PUERTOSERIE.CPP

/* panelSerie.cpp

**************************************/

#include <QtGui/QLayout>

#include <QtGui/QLineEdit>

#include <QtGui/QTextEdit>

#include <QtGui/QPushButton>

#include <QtGui/QComboBox>

#include <QtGui/QLabel>

#include <QtGui/QListWidget>

#include <QtGui/QMessageBox>

#include <QtCore/QList>

#include <QtCore/QIODevice> //no sé si hace falta(puerto serie,

funciones de Qt)

#include "panelSerie.h"

#include "addCOMDialog.h"

#include "configCOMDialog.h"

//panelSerie *wSerial; //puntero al widget PuertoSerie

#pragma comment (lib, "Setupapi.lib") //para evitar un problema con

qextserialenumerator

//al listar los puertos COM

instalados

//TIPOS DE CONFIGURACIONES DEL PUERTO SERIE

QList<BaudRateType> myBaudRateType = ( QList<BaudRateType>() << BAUD110 <<

BAUD300 << BAUD600

<< BAUD1200 << BAUD2400 << BAUD4800 << BAUD9600 << BAUD19200 <<

BAUD38400 );

QList<DataBitsType> myDataBitsType = ( QList<DataBitsType>() << DATA_7 <<

DATA_8 );

QList<ParityType> myParityType = ( QList<ParityType>() << PAR_NONE <<

PAR_ODD << PAR_EVEN );

QList<StopBitsType> myStopBitsType = (QList<StopBitsType>() << STOP_1 <<

STOP_2 );

QList<FlowType> myFlowType = ( QList<FlowType>() << FLOW_OFF <<

FLOW_HARDWARE << FLOW_XONXOFF );

panelSerie::panelSerie(QWidget* parent)

: QWidget(parent)

{

//Configuracion de parametros del puerto serie

//---------------------------------------------------------------------

-------

port = NULL;

163

/*

//.......................................................................

if (this->port->open(QIODevice::ReadWrite) == true) {

connect(this->port, SIGNAL(readyRead()), this,

SLOT(handleSerialData()));

qDebug() << "listening for data on" << this->port->portName();

//emit portOpened();

}

else {

qDebug() << "device failed to open:" << this->port->errorString();

//return false;

}

//.......................................................................

*/

message = new QLineEdit(this);

//Puerto de conexion serie

selectPort = new QComboBox();

selectPort->setDuplicatesEnabled(false); //evita elementos

duplicados NO FUNCIONA

stateCOM = new QLabel("Desconectado");

stateCOM->setStyleSheet("background-color: rgb(78, 210, 250)");

stateCOM->setFixedWidth(120);

stateCOM->setAlignment(Qt::AlignCenter); //Centra el texto contenido

en vertical y en horizontal

actCOMButton = new QPushButton("Activar COM");

addCOMButton = new QPushButton("Añadir puerto COM...");

configCOMButton = new QPushButton("Configurar COM...");

connect(actCOMButton, SIGNAL(clicked()), SLOT(EnablePort()) );

connect(addCOMButton, SIGNAL(clicked()), SLOT(showAddCOMDialog()) );

connect(configCOMButton, SIGNAL(clicked()), SLOT(showConfigCOMDialog())

);

QHBoxLayout* selectLayout = new QHBoxLayout;

selectLayout->addWidget(stateCOM);

selectLayout->addWidget(selectPort);

selectLayout->addWidget(actCOMButton);

selectLayout->addWidget(addCOMButton);

selectLayout->addWidget(configCOMButton);

selectLayout->addStretch(); //evita que los objetos se separen

mucho

//transmit receive

transmitButton = new QPushButton("Enviar");

receiveButton = new QPushButton("Recibir");

commandButton = new QPushButton("Enviar Comando");

connect(transmitButton, SIGNAL(clicked()), SLOT(transmitMsg()));

connect( message, SIGNAL(returnPressed()), transmitButton,

SIGNAL(clicked()) );

message->installEventFilter( this );// detecta eventos en el panel

this->setFocus();




164

connect(receiveButton, SIGNAL(clicked()), SLOT(receiveMsg()));

connect(commandButton, SIGNAL(clicked()), SLOT(commandMsg()));

QHBoxLayout* trLayout = new QHBoxLayout;

trLayout->addWidget(transmitButton);

trLayout->addWidget(receiveButton);

trLayout->addWidget(commandButton);

//CR LF

CRButton = new QPushButton("CR");

LFButton = new QPushButton("LF");

connect(CRButton, SIGNAL(clicked()), SLOT(appendCR()));

connect(LFButton, SIGNAL(clicked()), SLOT(appendLF()));

QHBoxLayout *crlfLayout = new QHBoxLayout;

crlfLayout->addWidget(CRButton);

crlfLayout->addWidget(LFButton);

//open close

openButton = new QPushButton("Abrir");

closeButton = new QPushButton("Cerrar");

connect(openButton, SIGNAL(clicked()), SLOT(openPort()));

connect(closeButton, SIGNAL(clicked()), SLOT(closePort()));

QHBoxLayout *ocLayout = new QHBoxLayout;

ocLayout->addWidget(openButton);

ocLayout->addWidget(closeButton);

sent_msg = new QTextEdit();

received_msg = new QTextEdit( );

//received_msg->setMinimumHeight(100);

QVBoxLayout *myVBox = new QVBoxLayout;

QLabel *titleSerial = new QLabel("PANEL PUERTO SERIE");

myVBox->addWidget(titleSerial);

myVBox->addLayout(selectLayout);

myVBox->addWidget(message);

QHBoxLayout *btnsLayout = new QHBoxLayout;

btnsLayout->addLayout(crlfLayout);

btnsLayout->addLayout(trLayout);

btnsLayout->addLayout(ocLayout);

btnsLayout->addStretch();

myVBox->addLayout(btnsLayout);

QHBoxLayout *msgLayout = new QHBoxLayout;

QVBoxLayout *msgSentLayout = new QVBoxLayout;

QVBoxLayout *msgReceivedLayout = new QVBoxLayout;

//QLabel Lb_sent("ENVIADO");

QLabel *Lb_sent = new QLabel("ENVIADO");

QLabel *Lb_received = new QLabel("RECIBIDO");

msgSentLayout->addWidget(Lb_sent);

msgSentLayout->addWidget(sent_msg);

msgReceivedLayout->addWidget(Lb_received);

msgReceivedLayout->addWidget(received_msg);




165

msgLayout->addLayout(msgSentLayout);

msgLayout->addLayout(msgReceivedLayout);

myVBox->addLayout(msgLayout);

setLayout(myVBox);

portList = new QStringList();

//Evitamos que se puelsen estos botones hasta que se haya conectado a

un puero COM

CRButton->setDisabled(true);

LFButton->setDisabled(true);

transmitButton->setDisabled(true);

commandButton->setDisabled(true);

openButton->setDisabled(true);

closeButton->setDisabled(true);

//En modo EventDriven se recibe de forma automatica -> habra que quitar

el boton de recibir

receiveButton->setDisabled(true);

sigComando.clear();

}

panelSerie::~panelSerie()

{

delete port;

//port = NULL;

}

void panelSerie::transmitMsg()

{

// this->appendCR();

// this->appendLF();

/* Con este metodo se separa la linea de texto a enviar del envio real

que

contiene los caracteres CR + LF en la terminacion. Asi no aparecen

lineas en blanco en la caja de texto enviado ni en el historial de

comandos enviados. */

// QString *cadenaEnviar = new QString("");

// cadenaEnviar->append( message->text() );

// this->appendCRcad( cadenaEnviar );

// this->appendLFcad( cadenaEnviar );

QString cadenaEnviar( message->text() );

this->appendCRcad( cadenaEnviar ); // paso por referencia

this->appendLFcad( cadenaEnviar );

message->home(false); //coloca cursor en el inicio sin seleccionar

nada

//int i = port->write( (message->text()).toAscii().constData(),

(message->text()).length());

// Si se ha configurado un puerto se envia el mensaje si no....

// EN ESTE CASO NO SE HACE NADA, se puede avisar u otra cosa

if ( port!= NULL )

166

{

// int i = port->write( (message->text()).toAscii(), (message-

>text()).length());

// int i = port->write( cadenaEnviar->toAscii(), cadenaEnviar-

>length() );

int i = port->write( cadenaEnviar.toAscii(), cadenaEnviar.length()

);

}

sent_msg->append(message->text());

////////////////////////

for ( int k=0; k<cadenaEnviar.length(); k++ ) {

qDebug() << "Caracter " + QString::number(k) + ": " +

QString(cadenaEnviar.at(k));

}

/////////////////////////

message->clear();

/*

QMutex m;

m.lock();

//port->flush();

int i = port->write( (message->text()).toAscii(), (message-

>text()).length());

//port->flush();

qDebug()<<"transmitted: "<<i;

m.unlock();

*/

/*

int i = port->write((message->text()).toAscii(),

(message->text()).length());

qDebug("trasmitted : %d", i);

*/

//message->clear();*/

}

void panelSerie::commandMsg() //al enviar un comando, se espera una

respuesta

{

/*

timeout->setInterval( 5000 ); // tiempo se espera maximo a una

respuesta de comando en ms

this->transmitMsg(); //Envía el comando e incia la cuenta

timeout->start();

*/

}

///////////////////////////////////////////////////////////////////////////

//////

void panelSerie::receiveMsg() //No sirve en modo Event Driven

{

//char buff[1024]; ya definido en la declaracion de clase

167

int numBytes;

numBytes = port->bytesAvailable();

if(numBytes > 1024)

numBytes = 1024;

int i = port->read(buffLectura, numBytes);

if (i != -1)

buffLectura[i] = '\0';

else

buffLectura[0] = '\0';

//-------------------------------------

// se pasa a sigComando los datos del buffer de lectura, que puede ser

un

// comando completo o una parte

// Se va añadiendo hasta que se detecta que se trata de un comando

completo

sigComando.append( buffLectura );

// se comprueba que es una terminacion de comando (CR,LF,.,\0)

QString terminacion;

for (int j=sigComando.size()-3; j<=sigComando.size(); j++) {

//USAR ENDSWITH

terminacion.append( sigComando.data()[j] );

}

if ( terminacion == QString( 0x13 + 0x10 + 0x46 + 0x00 ) ) { //

es un comando completo

emit comandoCompleto();

}

//-------------------------------------

received_msg->append( QString(buffLectura) ); // Cambiarlo de

forma que solo se muestre lo recibido en caso de que sea correcto

received_msg->ensureCursorVisible();

qDebug("bytes available: %d", numBytes);

qDebug("received: %d", i);

}

///////////////////////////////////////////////////////////////////////////

//////

void panelSerie::appendCR()

{

message->insert("\x0D");

}

void panelSerie::appendCRcad(QString &cadena)

{

cadena.append("\x0D");

}

void panelSerie::appendLF()

{

message->insert("\x0A"); // insert o append mejor ???

}

168

void panelSerie::appendLFcad(QString &cadena)

{

cadena.append("\x0A");

}

void panelSerie::closePort()

{

selectPort->setEnabled(true); //Evita poder activar otro puerto

mientras el actual permanece abierto

port->close();

qDebug() << port->portName() << "abierto?: " << int(port->isOpen());

stateCOM->setText(port->portName() + " activo - (Cerrado)");

CRButton->setDisabled(true);

LFButton->setDisabled(true);

transmitButton->setDisabled(true);

commandButton->setDisabled(true);

}

void panelSerie::openPort()

{

//Creo que asi no accede al buffer físico, por tanto habra que emplear

uno por software

if ( (this->port->open(QIODevice::ReadWrite | QIODevice::Unbuffered))

== true )

{

selectPort->setDisabled(true); //Evita poder activar otro puerto

mientras el actual permanece abierto

connect(this->port, SIGNAL(readyRead()), this,

SLOT(handleSerialData()));

connect(this->port, SIGNAL(bytesWritten(qint64)), this,

SLOT(reportWritten(qint64)));

qDebug() << port->portName() << "abierto?: " << int(port-

>isOpen());

qDebug() << "Puerto " << this->port->portName() << " abierto,

esperando a recibir datos...";

stateCOM->setText(port->portName() + " activo - (Abierto)");

CRButton->setEnabled(true);

LFButton->setEnabled(true);

transmitButton->setEnabled(true);

commandButton->setEnabled(true);

}

else {

qDebug() << "Fallo al abrir el puerto:" << this->port-

>errorString();

}

}

void panelSerie::detectCOMPorts()

{

//selectPort->addItem("Selecciona un puerto COM...");

//Si ejecutamos esto aqui como estaba vacio el combobox se activa la

señal de valueChanged

QList<QextPortInfo> listPorts = QextSerialEnumerator::getPorts();

169

qDebug() << "Detectando Puertos Serie Instalados... Lista de puertos

disponibles:\n";

for (int i = 0; i < listPorts.size(); i++) {

qDebug() << "port name: " << listPorts.at(i).portName;

qDebug() << "friendly name: " << listPorts.at(i).friendName;

qDebug() << "physical name: " << listPorts.at(i).physName;

qDebug() << "enumerator name: " << listPorts.at(i).enumName;

qDebug() << "===================================\n";

QString name = listPorts.at(i).portName;

//Almacena nombre COMx si i<9 o COMxx si i>=9 (suponiendo que

los nombres se

//obtengan de forma ordenada del registro de Windows)

//Por tanto permite detectar hasta 99 puertos serie

if (i < 9)

{

name.resize(4);

addCOMPort(name);

//selectPort->addItem(name);

}

else if( (i>=9) && (i<99) )

{

name.resize(5);

addCOMPort(name);

//selectPort->addItem(name);

}

}

}

//Establece la configuracion por defecto para el puerto serie,

//trabajando siempre en modo por Eventos e iniciandose cerrado.

void panelSerie::defaultConfigCOM(QString comx)

{

if ( port != NULL ) {

delete port;

}

port = new QextSerialPort(comx,QextSerialPort::EventDriven);

//IMPORTANTE ---> QExtSerialPort requiere abrir el puerto para

configurarlo

if(port->open(QIODevice::ReadWrite) == true)

{

port->setBaudRate(BAUD9600);

port->setDataBits(DATA_8);

port->setParity(PAR_NONE);

port->setStopBits(STOP_1);

port->setFlowControl(FLOW_HARDWARE);

}

port->close();

//---------------------------------------------------------------------

-----

qDebug() << "Conectado al puerto: " << comx <<"\n";

stateCOM->setText(comx + " activo - (Cerrado)");

}

//Activa el puerto indicado como puerto serie con la configuracion por

defecto

170

void panelSerie::EnablePort()

{

QString nPort = selectPort->currentText();

if (nPort == "Selecciona un puerto COM..."){

int ret = QMessageBox::warning(this, tr("Aviso"),

tr("No se ha especificado un valor de

puerto serie COMxx correcto."),

QMessageBox::Close ,

QMessageBox::Close);

}

else{

//Al activar cualquier puerto se activa con la configuracion por

defecto, luego se puede cambiar

//desde el boton de Configurar

this->defaultConfigCOM(nPort);

openButton->setEnabled(true);

closeButton->setEnabled(true);

}

}

void panelSerie::showAddCOMDialog()

{

addCOMButton->disconnect(); //evita que se abran varios paneles

de añadir puerto

addCOMDialog *insertPort = new addCOMDialog();

insertPort->show();

connect( insertPort, SIGNAL(newCOM(QString)), this ,

SLOT(addCOMPort(QString)) );

connect( insertPort, SIGNAL(finishNewCOM()), this,

SLOT(closedAddCOMDialog()) );

}

void panelSerie::addCOMPort(QString comPort)

{

int j = 0;

int actualPort = portList->value(j).remove(0,3).toInt();

QString textNumPort = comPort;

textNumPort.remove(0,3); //elimina texto COM dejando solo el numero de

puerto a añadir (mas facil ordenar enteros que strings)

int numPort = textNumPort.toInt();

while ( (j < portList->size()) && (numPort > actualPort) )

{

j++;

actualPort = portList->value(j).remove(0,3).toInt();

}

if( numPort == actualPort )

{

return;

}

else //caso de ser el numPort mayor que actualPort

{

portList->insert(j,comPort);

}

selectPort->clear();

selectPort->addItem("Selecciona un puerto COM...");

171

selectPort->addItems(*portList);

connect( addCOMButton, SIGNAL(clicked()), this,

SLOT(showAddCOMDialog()) );

}

void panelSerie::closedAddCOMDialog()

{

connect( addCOMButton, SIGNAL(clicked()), this,

SLOT(showAddCOMDialog()) );

}

void panelSerie::showConfigCOMDialog()

{

//debe haberse activado algún puerto y estar cerrado para poderse

configurar

if ( (port == NULL) || (port->isOpen()) )

{

int ret = QMessageBox::warning(this, tr("Aviso"),

tr("No se ha activado ningún puerto o el

puerto activo está abierto."),

QMessageBox::Close ,

QMessageBox::Close);

return;

}

configCOMButton->disconnect(); //evita que se abran varios

paneles de configurar puerto

configCOMDialog *configPort = new configCOMDialog();

configPort->show();

connect( configPort, SIGNAL(paramsCOM(QList<int>)), this ,

SLOT(configCOMPort(QList<int>)) );

connect( configPort, SIGNAL(finishConfigCOM()), this,

SLOT(closedConfigCOMDialog()) );

}

void panelSerie::configCOMPort(QList<int> list)

{

QStringList stringBaudRateType = ( QStringList() << "110" << "300" <<

"600" << "1200"

<< "2400" << "4800" << "9600" << "19200" << "38400" );

QStringList stringDataBitsType = ( QStringList() << "7" << "8" );

QStringList stringParityType = ( QStringList() << "Ninguna" << "Par" <<

"Impar" );

QStringList stringStopBitsType = ( QStringList() << "1" << "2" );

QStringList stringFlowType = ( QStringList() << "Ninguno" << "Hardware"

<< "Software" );

this->baud = list.at(0);

this->bits = list.at(1);

this->par = list.at(2);

this->stop = list.at(3);

this->flow = list.at(4);

//Se debe haber activado un puerto antes, sino la variable port tendrá

NULL y dara error lo siguiente

port->setBaudRate( myBaudRateType.at(baud) );

port->setDataBits( myDataBitsType.at(bits) );

port->setParity( myParityType.at(par) );

172

port->setStopBits( myStopBitsType.at(stop) );

port->setFlowControl( myFlowType.at(flow) );

qDebug() << "Puerto " << port->portName() << " configurado:";

qDebug() << "-------------------------------------------";

qDebug() << "Baudios:\t\t" << stringBaudRateType.at(baud);

qDebug() << "Bits de datos:\t" << stringDataBitsType.at(bits);

qDebug() << "Tipo de paridad:\t" << stringParityType.at(par);

qDebug() << "Bits de stop:\t" << stringStopBitsType.at(stop);

qDebug() << "Control de flujo:\t" << stringFlowType.at(flow);

connect( configCOMButton, SIGNAL(clicked()), this,

SLOT(showConfigCOMDialog()) );

}

void panelSerie::closedConfigCOMDialog()

{

connect( configCOMButton, SIGNAL(clicked()), this,

SLOT(showConfigCOMDialog()) );

}

//----------------------------------------------------------------

void panelSerie::handleSerialData()

{

// comprobamos que se puede leer del puerto, caso que no, se sale de

la funcion

if (! port->isOpen())

return;

//se obtiene el nº de bytes disponibles para leer

//y se limita como maximo a 1024 caracteres

int numBytes = this->port->bytesAvailable();

/*BORRAR*/ //numBytes = 2;

if (numBytes > 0)

{

char buffer[1024];

if (numBytes > 1023)

{

numBytes = 1023;

qDebug() << "Aviso: Se ha superado el tamaño del buffer.";

}

int i = this->port->read(buffer, numBytes);

/*

/// ESTO ES DE PRUEBA BORRAR.... para leer respuesta comando where

buffer[0] = 0x77; buffer[1] = 0x68; buffer[2] = 0x1b;

buffer[3] = 0x5b; buffer[4] = 0x34; buffer[5] = 0x6c;

buffer[6] = 0xd; buffer[7] = 0xa; buffer[8] = 0x20;

buffer[9] = 0x20; buffer[10] = 0x20; buffer[11] = 0x20;

173

buffer[33] = 0x20; buffer[34] = 0x5a; buffer[35] = 0x20;





buffer[48] = '\0';

////--------------------------------------------------------

//buffer[numBytes] = '\0';

/// codigo de prueba ---- borrar despues

for (int i=0; i<numBytes; i++)

{

qDebug() << hex << buffer[i];

}

/// -------------------------------------

*/

buffer[numBytes] = '\0';

//received_msg->append( QString(buffer) );

received_msg->insertPlainText( QString(buffer) );

received_msg->ensureCursorVisible();

qDebug("bytes available: %d", numBytes);

qDebug("received: %d", i);

}

}

//----------------------------------------------------------------

void panelSerie::reportWritten(qint64 numBytesWritten)

{

qDebug() << "transmitted: " << numBytesWritten;

//Solo funciona con los puertos serie reales instalados en el pc,

//no válido con el simulado mediante programa externo

}

// NO FUNCIONA

//??????????????????????????????????????

bool panelSerie::eventFilter( QObject *object, QEvent *event )

{

if ( object == message ) {

if ( event->type() == QEvent::KeyPress ) {

QKeyEvent *eventoTeclado = dynamic_cast<QKeyEvent*>( event );

// ???? NO SE POR QUE METE LINEAS EN BLANCO

if ( eventoTeclado->key() == Qt::Key_Up ) {

message->undo();

if ( message->text() == "" ) {

message->undo();

}

return true;

}




174

else if ( eventoTeclado->key() == Qt::Key_Down ) {

message->redo();

if ( message->text() == "" ) {

message->redo();

}

return true;

}

}

}

return false;

}

175

PANELPROGRAMA.H

#ifndef PANELPROGRAMA_H

#define PANELPROGRAMA_H


#include <QtGui/QPlainTextEdit>

#include <QtGui/QFileDialog>

#include <QtCore/QTextStream>

#include <QtCore/QFile>



#include <QtCore/QTimer>

#include "CodeEditor.h"

namespace Ui {

class panelProgramar;

}

class panelPrograma : public QMainWindow

{

Q_OBJECT

public:

panelPrograma( QWidget *parent = 0, Qt::WFlags flags = 0 );

~panelPrograma();

private:

Ui::panelProgramar *ui;

// si debe tener mas terminos se puede meter en un struct o clase

QFile *fichActual;

QString nombreFichAct;

bool finTiempo;

QTimer timer;

CodeEditor *cajaTexto;

// variables

QFont fuente;

private slots:

void abrirFichero();

void guardarFicheroPC();

void panelConfig();

void cambiarFuente();

void enviarProg();

void finalizarTiempo();




176

};

#endif




177

PANELPROGRAMA.CPP

#include "panelPrograma.h"

#include "ui_panelProgramar.h"


extern panelSerie *wSerial;

panelPrograma::panelPrograma( QWidget *parent /*= 0*/, Qt::WFlags flags /*=

0*/ )

: QMainWindow(parent), ui(new Ui::panelProgramar)

{

ui->setupUi(this);

cajaTexto = new CodeEditor;

ui->vlay_central->addWidget( cajaTexto );

fuente = QFont ("Consolas", 11);

cajaTexto->setFont( fuente );

fichActual = NULL;

/// Conexiones

// Menus

// Menu Archivo

ui->actionAbrir->setDisabled(true);

ui->actionGuardar_como->setDisabled(true);

ui->actionCerrar->setDisabled(true);

ui->actionDeshacer->setDisabled(true);

ui->actionRehacer->setDisabled(true);

ui->actionCortar->setDisabled(true);

ui->actionCopiar->setDisabled(true);

ui->actionPegar->setDisabled(true);

ui->actionEnviar_y_ejecutar->setDisabled(true);

ui->actionAlmacenar_en_memoria->setDisabled(true);

ui->actionLeer_de_memoria->setDisabled(true);

ui->actionVer_directorio->setDisabled(true);

connect( ui->actionAbrir,SIGNAL(triggered()),this,SLOT(abrirFichero())

);

connect( ui->actionGuardar,SIGNAL(triggered()),this,

SLOT(guardarFicheroPC()) );

connect( ui->actionSalir,SIGNAL(triggered()),this,SLOT(close()) );

connect( ui-

>actionConfigurar,SIGNAL(triggered()),this,SLOT(panelConfig()) );

// Botones

connect( ui->pbGuardar,SIGNAL(clicked()),this,SLOT(guardarFicheroPC())

);

connect( ui->pbCargar,SIGNAL(clicked()),this,SLOT(abrirFichero()) );

connect( ui->pbEnviar ,SIGNAL(clicked()),this,SLOT(enviarProg()) );




178

}

panelPrograma::~panelPrograma()

{

}

void panelPrograma::abrirFichero()

{

nombreFichAct = QFileDialog::getOpenFileName( this,

tr("Abrir Programa"), "", tr("Fichero de programa VSS60

(*.vssp);;") +

tr("Archivo de texto (*.txt)") );

if ( nombreFichAct != "" ) {

if ( fichActual != NULL)

{ delete fichActual; }

fichActual = new QFile;

fichActual->setFileName( nombreFichAct );

if ( fichActual->open(QIODevice::ReadWrite) ) {

cajaTexto->clear();

QTextStream stream( fichActual) ;

cajaTexto->setPlainText( stream.readAll() ); // creo que

va bien. VER SI SE PUEDE CON >>

fichActual->flush();

fichActual->close();

}

else {

QMessageBox::critical( this, tr("Error"),

tr("No se pudo abrir el fichero.") );

return;

}

}

}

void panelPrograma::guardarFicheroPC()

{

if ( fichActual != NULL)

{ delete fichActual; }

fichActual = new QFile;

nombreFichAct = QFileDialog::getSaveFileName( this,

tr("Guardar Programa"), "", tr("Fichero de programa VSS60

(*.vssp);;") +

tr("Archivo de texto (*.txt)") ); // cuidado porque NO

coinciden con los V2

//

del controlador no se pueden meter en un disquete

179

if ( nombreFichAct != "" ) {

fichActual->setFileName( nombreFichAct );

ui->lineEdit->setText( nombreFichAct );

if ( fichActual->open(QIODevice::ReadWrite) ) {

QTextStream stream( fichActual) ;

stream << cajaTexto->toPlainText();

fichActual->flush();

fichActual->close();

}

else {

QMessageBox::critical( this, tr("Error"),

tr("No se pudo guardar el fichero.") );

return;

}

}

}

void panelPrograma::enviarProg()

{

// Creo que sera mejor hacer el panel como widget y meterlo dentro de

la

// ventana ppal. Ver si es mejor asi (lo de variable globales no me

// convence, a no ser que sea algo muy especifico)

// Guardar el texto del programa en una variable cadena de caracteres

/*

VER SI ES MEJOR ASI O LEER DE UN FICHERO

Asi parece mas facil

*/

QString textoPrograma = cajaTexto->toPlainText();

QStringList lineasPrograma = textoPrograma.split( // separa por

los saltos de linea y elimina lineas vacias

"\n", QString::SkipEmptyParts );

// Si no esta vacio el texto del programa

if ( textoPrograma.size() > 0 )

{

// Si se ha configurado un puerto serie

if ( wSerial->port != NULL ) {

for ( int i = 0; i < lineasPrograma.size(); i++ ) {

QString mensaje = lineasPrograma.at(i);

mensaje.append( "\x0D" ); // CR

mensaje.append( "\x0A" ); // LF

/// codigo de prueba ---- borrar despues

for (int i=0; i<mensaje.length(); i++)

{

QString prueba = mensaje.at(i).toAscii();

qDebug() << hex << prueba;

}

/// -------------------------------------

int envio = wSerial->port->write(

mensaje.toAscii(),

180

mensaje.length() );

/// MUY IMPORTANTE SI NO NO SE ENVIA CORRECTAMENTE

// nº intentos o tiempo , flush igual va por cada byte ???

en ese caso son bastantes

/*int intentos = 20;*/

connect(&timer,SIGNAL(timeout()),this,SLOT(finalizarTiempo()));

finTiempo = false;

timer.start(0.01); // 1 ms

while ( (wSerial->port->bytesToWrite() > 0) || (!finTiempo)

/*&& (intentos>0)*/ ) {

wSerial->port->flush();

QCoreApplication::processEvents(QEventLoop::AllEvents,

100);

/*intentos--;*/

}

//timer.stop();

// REVISAR QIODEVICE metodos y signals

// Revisar QextSerialPort::atEnd() en lugar de

QextSerialPort::bytesAvailable()

if( wSerial->port->bytesToWrite() > 0 ){ qDebug() << "Error

al enviar la linea: " << mensaje; }

//------------- otra opcion

// if ( envio != mensaje.length() ) {

// qDebug("Fallo al escribir el comando. Solo se

escribieron %d bytes", envio);

// //REENVIAR...

// }

///-------------------------------------------------

qDebug() << "envio = " << envio;

//Mostrar

wSerial->sent_msg->append( mensaje );

}

}

else

{

QMessageBox::warning( this, tr("Aviso"),

tr("No se ha configurado ningún puerto serie.") );

}

}

// Si está vacío sólo muestra un aviso

else

{

QMessageBox::warning( this, tr("Aviso"),

tr("El programa está vacío.") );

}

181

}

void panelPrograma::finalizarTiempo()

{

finTiempo = true;

//qDebug() << "FIN DEL TIEEEEEEEEEEEEEEEEEEEEEEEEEMPO";

}

void panelPrograma::panelConfig()

{

}

void panelPrograma::cambiarFuente()

{

}

182

PANELMOVER.H

#ifndef PANELMOVER_H

#define PANELMOVER_H

#include <QtGui/QDockWidget>

#include <QtGui/QSlider>

#include <QtCore/QSignalMapper>

#include <QtCore/QTimer>

namespace Ui {

class panelMover;

}

class panelMover : public QDockWidget

{

Q_OBJECT

public:

explicit panelMover(QWidget *parent = 0, Qt::WFlags flags = 0);

~panelMover();

QTimer *tiempo;

private:

Ui::panelMover *ui;

QSignalMapper *mapper_spinB;

QSlider *p_slider;

double ang[6]; //valores galmacenados de los angulos actuales

public slots:

void cambioSpin(double);

void cambioSlider(int);

void moverEslabones();

void mostrar(bool);

void seguir(bool);

void preguntarPosicion();

void interpretarPosicion();

};

#endif

183

PANELMOVER.CPP

#include <QtCore/QString>

#include "panelMover.h"

#include "ui_panelMover.h"


extern panelSerie *wSerial;


extern StaubliRX60 *robot;


panelMover::panelMover(QWidget *parent, Qt::WFlags flags) :

QDockWidget(parent, flags),

ui(new Ui::panelMover)

{

ui->setupUi(this);

// Reservar memoria para el temporizador de ciclo de lectura de

posicion

tiempo = new QTimer;

for(int i = 0; i <= 6; i++){ //Inicializamos todos los valores de

ang[] a 0

ang[i] = 0.0;

}

connect(ui->spinbJ1, SIGNAL(valueChanged(double)), this, SLOT

(cambioSpin(double)));











connect(ui->hSliderJ1, SIGNAL(valueChanged(int)), this, SLOT

(cambioSlider(int)));











connect(ui->btnMover, SIGNAL(clicked()), this, SLOT

(moverEslabones()));




184

//Revisar esto (y todo) porque igual no debe hacerse asi

connect(ui->rBtn_mostrar, SIGNAL(clicked(bool)), this,

SLOT(mostrar(bool)));

connect(ui->rBtn_seguir, SIGNAL(clicked(bool)), this,

SLOT(seguir(bool)));

// Inicialmente esta marcada la opcion de que se muestren en 3d los

giros

// enviados por el puerto serie (si todo funciona correctamente deben

// coincidir con los giros reales efectuados por el robot).

// ui->rBtn_mostrar->setChecked(true);

//mostrar(true); NO FUNCIONA LA PRIMERA VEZ

}

panelMover::~panelMover()

{

delete ui;

}

void panelMover::cambioSpin(double d)

{

//El parametro de entrada "d" no se usa, solo es necesario para poder

llamar al slot

//desde la señal valueChanged()

ui->hSliderJ1->setValue( int(ui->spinbJ1->value() * 10) );






}

void panelMover::cambioSlider(int i)

{

//El parametro de entrada "i" no se usa, solo es necesario para poder

llamar al slot

//desde la señal valueChanged()

ui->spinbJ1->setValue( ui->hSliderJ1->value() / 10.0 );






}

//SUPONIENDO SOLO PUEDE CAMBIAR UN ANGULO CADA VEZ QUE SE PULSA EL BOTON DE

MOVER

// envia la posicion de destino al robot, solo puede girar una unica

articulacion

// cada vez que se pulsa el boton mover aunque puede almacenar el giro de

185

varias

void panelMover::moverEslabones()

{

QString girarJ;

double diff[6];

//Diferencias entre los angulos marcados por los controles y los

almacenados anteriormente

diff[0] = ui->spinbJ1->value() - ang[0];






for (int i=0; i<=5; i++)

{

if( abs(diff[i]) >= 0.1 )

{

girarJ = "DO DRIVE " + QString::number(i+1) + "," +

QString::number(diff[i]) + ",100";

wSerial->message->insert( girarJ );

wSerial->transmitMsg();

ang[i] = ang[i]+diff[i];

break;

}

}

}

// Muestra en el modelo 3D la posicion indicada con los valores del panel

mover

void panelMover::mostrar(bool b)

{

if (b == true) {

//if ( tiempo->isActive() )

//{

// tiempo->stop();

// this->disconnect( tiempo, SIGNAL(timeout()), this,

SLOT(preguntarPosicion()) );

//}

connect(ui->spinbJ1, SIGNAL(valueChanged(double)),

guiMain->DSpinBox1_actual, SLOT(setValue(double)));











if (tiempo->isActive())

{

tiempo->stop();

}

186

disconnect( wSerial, SIGNAL(comandoCompleto()), this,

SLOT(interpretarPosicion()) );

}

}

void panelMover::seguir(bool b)

{

if (b == true) {

// Temporizador where, cada 200 ms, 5 veces por segundo

//tiempo->setInterval(200);

tiempo->setInterval(50);

connect(tiempo,SIGNAL(timeout()),this,SLOT(preguntarPosicion()));

tiempo->start();

connect( wSerial, SIGNAL(comandoCompleto()), this,

SLOT(interpretarPosicion()) );

//mejor hacerlo de forma que espere hasta que se complete la

respuesta para que sea mas sencillo

}

}

void panelMover::preguntarPosicion()

{

//si no hay envios ni se esta recibiendo, se pregunta la posicion

if ( (wSerial->port->bytesToWrite() == 0) &&

(wSerial->port->bytesAvailable() == 0) ) {

// Pregunta la posicion

wSerial->message->insert( "WH" );

wSerial->transmitMsg();

}

// SE CONGELA

// Lee la respuesta de posicion y la almacena en una cadena

}

void panelMover::interpretarPosicion()

{

QString respuesta;

respuesta = wSerial->sigComando;

if ( respuesta.startsWith( "wh" + QString(0x27 + 0x91 + 0x52 + 0x108 +

0x13 + 0x10) ) ) {

//entonces es un comando "where"

qDebug() << "Ha llegado un mensaje de tipo WHERE";

}

}




187

188

VENTANAMENSAJES.H

/**

* @file ventanaMensajes.h

* @brief Message Window.

* @see ventanaMensajes

* @author Micha³ Policht

*/

#ifndef ventanaMensajes_H_

#define ventanaMensajes_H_

#include <QtGui/QDockWidget>

#include <QtGui/QTextEdit>

#include <QtCore/QEvent>

/**

* Message Window. Handling errors and other messages.

*/

class ventanaMensajes: public QDockWidget

{

Q_OBJECT

QTextEdit msgTextEdit; ///< Main widget.

static ventanaMensajes* MsgHandler; ///< Set in constructor.

static const char* WINDOW_TITLE; ///< Window title.

private:

static QString QtMsgToQString(QtMsgType type, const char *msg);

protected:

/**

* Handle custom events. ventanaMensajes hadles custom events

listed in

* EventType enum.

*/

virtual void customEvent(QEvent* event);

public: //!!!!!!!! Comprobar

por que ponia 1001

enum EventType {MessageEvent = /*1001*/QEvent::User}; ///<

Custom event types.

/**

* Default constructor.

* @param parent parent widget.

* @param flags widget flags.

*/

ventanaMensajes(QWidget* parent = 0, Qt::WFlags flags = 0);

/**

* Append message wrapper. Since ISO forbids casting member

functions

* to C functions, wrapper is needed to use this class as

QtMsgHandler.

* This method is thread-safe but not reentrant.

* @param type message type.

* @param msg message string.

*/

189

static void AppendMsgWrapper(QtMsgType type, const char *msg);

/**

* Post message event to the main event loop. This function

encapsulates

* message into MessageEvent object and passes it to the main event

loop.

* @param type message type.

* @param msg message string.

*/

void postMsgEvent(QtMsgType type, const char *msg);

};

/**

* Message Event. Custom event used by @ref ventanaMensajes to provide

multi-threaded

* access. Encapsulates message inside @a msg variable.

*/

class MessageEvent: public QEvent

{

public:

QString msg; ///< Message string.

/**

* Contructor.

* @param msg message to post.

*/

MessageEvent(QString & msg);

};

#endif /*ventanaMensajes_H_*/

190

VENTANAMENSAJES.CPP

/**

* @file ventanaMensajes.cpp

* @brief ventanaMensajes Implementation.

* @see ventanaMensajes.h

* @author Micha³ Policht

*/

/*

==============

<INIT>

==============

*/

#include "ventanaMensajes.h"


#include <QtCore/QCoreApplication>

#include <QtCore/QMutexLocker>

const char* ventanaMensajes::WINDOW_TITLE = "Message Window";

ventanaMensajes* ventanaMensajes::MsgHandler = NULL;

/*

==============

<CONSTRUCTORS>

==============

*/

ventanaMensajes::ventanaMensajes(QWidget* parent, Qt::WFlags flags)

: QDockWidget(parent, flags),

msgTextEdit(this)

{

setWindowTitle(tr(WINDOW_TITLE));

msgTextEdit.setReadOnly(true);

setWidget(&msgTextEdit);

ventanaMensajes::MsgHandler = this;

//Prueba de tamaño . En realidad depende de donde este colocada la

barra, depende de otros widgets

//this->msgTextEdit.setSizePolicy( QSizePolicy::Preferred,

QSizePolicy::Expanding );;

}

/*

==============

<DESTRUCTOR>

==============

*/

/*

==============

<SLOTS>

==============

191

*/

/*

==============

<METHODS>

==============

*/

//static

QString ventanaMensajes::QtMsgToQString(QtMsgType type, const char *msg)

{

switch (type) {

case QtDebugMsg:

return QString("Debug: ")+QString(msg);

case QtWarningMsg:

return QString("Warning: ")+QString(msg);

case QtCriticalMsg:

return QString("Critical: ")+QString(msg);

case QtFatalMsg:

return QString("Fatal: ")+QString(msg);

default:

return QString("Unrecognized message type: ")+QString(msg);

}

}

//static

void ventanaMensajes::AppendMsgWrapper(QtMsgType type, const char* msg)

{

static QMutex mutex;

QMutexLocker locker(&mutex);

if (ventanaMensajes::MsgHandler != NULL)

return ventanaMensajes::MsgHandler->postMsgEvent(type, msg);

else

fprintf(stderr, ventanaMensajes::QtMsgToQString(type,

msg).toAscii());

}

void ventanaMensajes::customEvent(QEvent* event)

{

if (static_cast<ventanaMensajes::EventType>(event->type()) ==

ventanaMensajes::MessageEvent)

msgTextEdit.append(dynamic_cast</*MessageEvent*/::MessageEvent*

>(event)->msg); //comprobar por qué funciona así

}

void ventanaMensajes::postMsgEvent(QtMsgType type, const char* msg)

{

QString qmsg = ventanaMensajes::QtMsgToQString(type, msg);

switch (type) {

case QtDebugMsg:

break;

case QtWarningMsg:

qmsg.prepend("");

qmsg.append("");

break;

case QtCriticalMsg:

if (QMessageBox::critical(this, "Critical Error", qmsg,

QMessageBox::Ignore,

192

QMessageBox::Abort,

QMessageBox::NoButton) == QMessageBox::Abort)

abort(); // core dump

qmsg.prepend("");

qmsg.append("");

break;

case QtFatalMsg:

QMessageBox::critical(this, "Fatal Error", qmsg,

QMessageBox::Ok, QMessageBox::NoButton, QMessageBox::NoButton);

abort(); // deliberately core dump

}

//it's impossible to change GUI directly from thread other than the

main thread

//so post message encapsulated by MessageEvent to the main thread's

event queue

QCoreApplication::postEvent(this, new

/*MessageEvent*/::MessageEvent(qmsg)); //comprobar por qué funciona así

}

/*

==============

<HELPERS>

==============

*/

MessageEvent::MessageEvent(QString & msg):

QEvent(static_cast<QEvent::Type>(ventanaMensajes::MessageEvent))

{

this->msg = msg;

}

193

CONFIGCOMDIALOG.H

#ifndef CONFIGCOMDIALOG_H

#define CONFIGCOMDIALOG_H

#include <QtGui/QDialog>

namespace Ui {

class configCOMDialog;

}

class configCOMDialog : public QDialog

{

Q_OBJECT

public:

explicit configCOMDialog(QWidget *parent = 0);

~configCOMDialog();

//QString getCOMToAdd(); //devuelve el nombre del puerto COM a

añadir

public slots:

void acceptClicked();

private:

Ui::configCOMDialog *ui;

//public slots:

//void addClicked(); //añade al combobox el nuevo puerto COM

signals:

void paramsCOM(QList<int>);

void finishConfigCOM();

private:

void closeEvent(QCloseEvent*);

};

#endif // CONFIGCOMDIALOG_H

194

CONFIGCOMDIALOG.CPP

#include "configCOMDialog.h"

#include "ui_configCOMDialog.h"

#include <QtCore/QList>

configCOMDialog::configCOMDialog(QWidget *parent) : QDialog(parent), ui(new

Ui::configCOMDialog)

{

// Cargamos la interfaz prediseñada.

ui->setupUi(this);

QList<int> stringlist;

emit paramsCOM(stringlist);

/*QLabel *label = new QLabel("Introducir puerto COM -> ");

numSpin = new QSpinBox();

numSpin->setMinimum(1);

numSpin->setMaximum(99);

numSpin->setValue(1);

addButton = new QPushButton("Insertar puerto en lista");

QHBoxLayout *comLayout = new QHBoxLayout();

comLayout->addWidget(label);

comLayout->addWidget(numSpin);

QVBoxLayout *addCOMLayout = new QVBoxLayout();

addCOMLayout->addLayout(comLayout);

addCOMLayout->addWidget(addButton);

this->setLayout(addCOMLayout);

this->resize(200,150);

this->setWindowTitle("Incluir puerto COM");

//ajusta la ventana al contenido y la centra en pantalla

this->adjustSize();

this->move(QApplication::desktop()->screen()->rect().center() - this-

>rect().center());

connect(addButton, SIGNAL(clicked()), this, SLOT(addClicked()));

*/

connect( ui->buttonBox, SIGNAL(accepted()), this, SLOT(acceptClicked())

);

connect( ui->buttonBox, SIGNAL(rejected()), this, SLOT(close()) );

}

configCOMDialog::~configCOMDialog()

{

delete ui;

}

void configCOMDialog::acceptClicked()

{

/*QString comPort = QString::number( numSpin->value() );

comPort = "COM" + comPort;*/

QList<int> paramsList;




195

paramsList.append( ui->comboBox_vel->currentIndex() );

paramsList.append( ui->comboBox_bits->currentIndex() );

paramsList.append( ui->comboBox_par->currentIndex() );

paramsList.append( ui->comboBox_stop->currentIndex() );

paramsList.append( ui->comboBox_flow->currentIndex() );

emit paramsCOM(paramsList);

this->close();

}

void configCOMDialog::closeEvent(QCloseEvent *event)

{

emit finishConfigCOM();

}

196

CODEEDITOR.H

#include <QtGui/QWidget>


#include <QtGui/QPainter>

#include <QtGui/QTextBlock>

class CodeEditor : public QPlainTextEdit

{

Q_OBJECT

public:

CodeEditor(QWidget *parent = 0);

void lineNumberAreaPaintEvent(QPaintEvent *event);

int lineNumberAreaWidth();

protected:

void resizeEvent(QResizeEvent *event);

private slots:

void updateLineNumberAreaWidth(int newBlockCount);

void highlightCurrentLine();

void updateLineNumberArea(const QRect &, int);

private:

QWidget *lineNumberArea;

};




197

CODEEDITOR.CPP

#include "CodeEditor.h"

class LineNumberArea : public QWidget

{

public:

LineNumberArea(CodeEditor *editor) : QWidget(editor) {

codeEditor = editor;

}

QSize sizeHint() const {

return QSize(codeEditor->lineNumberAreaWidth(), 0);

}

protected:

void paintEvent(QPaintEvent *event) {

codeEditor->lineNumberAreaPaintEvent(event);

}

private:

CodeEditor *codeEditor;

};

CodeEditor::CodeEditor(QWidget *parent) : QPlainTextEdit(parent)

{

lineNumberArea = new LineNumberArea(this);

connect(this, SIGNAL(blockCountChanged(int)), this,

SLOT(updateLineNumberAreaWidth(int)));

connect(this, SIGNAL(updateRequest(QRect,int)), this,

SLOT(updateLineNumberArea(QRect,int)));

connect(this, SIGNAL(cursorPositionChanged()), this,

SLOT(highlightCurrentLine()));

updateLineNumberAreaWidth(0);

highlightCurrentLine();

}

int CodeEditor::lineNumberAreaWidth()

{

int digits = 1;

int max = qMax(1, blockCount());

while (max >= 10) {

max /= 10;

++digits;

}

int space = 10 + fontMetrics().width(QLatin1Char('9')) * digits;

return space;

}

void CodeEditor::updateLineNumberAreaWidth(int /* newBlockCount */)

{

setViewportMargins(lineNumberAreaWidth(), 0, 0, 0);

198

}

void CodeEditor::updateLineNumberArea(const QRect &rect, int dy)

{

if (dy)

lineNumberArea->scroll(0, dy);

else

lineNumberArea->update(0, rect.y(), lineNumberArea->width(),

rect.height());

if (rect.contains(viewport()->rect()))

updateLineNumberAreaWidth(0);

}

void CodeEditor::resizeEvent(QResizeEvent *e)

{

QPlainTextEdit::resizeEvent(e);

QRect cr = contentsRect();

lineNumberArea->setGeometry(QRect(cr.left(), cr.top(),

lineNumberAreaWidth(), cr.height()));

}

void CodeEditor::highlightCurrentLine()

{

QList<QTextEdit::ExtraSelection> extraSelections;

if (!isReadOnly()) {

QTextEdit::ExtraSelection selection;

QColor lineColor = QColor(Qt::yellow).lighter(160);

selection.format.setBackground(lineColor);

selection.format.setProperty(QTextFormat::FullWidthSelection,

true);

selection.cursor = textCursor();

selection.cursor.clearSelection();

extraSelections.append(selection);

}

setExtraSelections(extraSelections);

}

void CodeEditor::lineNumberAreaPaintEvent(QPaintEvent *event)

{

QPainter painter(lineNumberArea);

painter.fillRect(event->rect(), Qt::lightGray);

QTextBlock block = firstVisibleBlock();

int blockNumber = block.blockNumber();

int top = (int)

blockBoundingGeometry(block).translated(contentOffset()).top();

int bottom = top + (int) blockBoundingRect(block).height();

while (block.isValid() && top <= event->rect().bottom()) {

if (block.isVisible() && bottom >= event->rect().top()) {

QString number = QString::number(blockNumber + 1);

painter.setPen(Qt::black);

painter.drawText(0, top, lineNumberArea->width(),

fontMetrics().height(),




199

Qt::AlignRight, number);

}

block = block.next();

top = bottom;

bottom = top + (int) blockBoundingRect(block).height();

++blockNumber;

}

}

200

ADDCOMDIALOG.H

#ifndef ADDCOMDIALOG_H

#define ADDCOMDIALOG_H

#include <QDialog>

#include <QHBoxLayout>

#include <QVBoxLayout>

#include <QLabel>

#include <QSpinBox>

#include <QPushButton>

#include <QApplication>

#include <QDesktopWidget>

class addCOMDialog : public QWidget

{

Q_OBJECT

public:

addCOMDialog(QWidget *parent = 0);

QString getCOMToAdd(); //devuelve el nombre del puerto COM a

añadir

public slots:

void addClicked(); //añade al combobox el nuevo puerto COM

signals:

void newCOM(QString);

void finishNewCOM();

private:

QPushButton *addButton;

//QLineEdit *nameEdit;

QSpinBox *numSpin;

QString nameText;

void closeEvent(QCloseEvent*);

//void acceptCliked();

};

#endif // ADDCOMDIALOG_H




201

ADDCOMDIALOG.CPP

#include "addCOMDialog.h"


extern panelSerie *wSerial; //puntero al widget PuertoSerie

addCOMDialog::addCOMDialog(QWidget *parent)

: QWidget(parent)

{

QLabel *label = new QLabel("Introducir puerto COM -> ");

numSpin = new QSpinBox();

numSpin->setMinimum(1);

numSpin->setMaximum(99);

numSpin->setValue(1);

addButton = new QPushButton("Insertar puerto en lista");

QHBoxLayout *comLayout = new QHBoxLayout();

comLayout->addWidget(label);

comLayout->addWidget(numSpin);

QVBoxLayout *addCOMLayout = new QVBoxLayout();

addCOMLayout->addLayout(comLayout);

addCOMLayout->addWidget(addButton);

this->setLayout(addCOMLayout);

this->resize(200,150);

this->setWindowTitle("Incluir puerto COM");

//ajusta la ventana al contenido y la centra en pantalla

this->adjustSize();

this->move(QApplication::desktop()->screen()->rect().center() - this-

>rect().center());

connect(addButton, SIGNAL(clicked()), this, SLOT(addClicked()));

}

void addCOMDialog::addClicked()

{

QString comPort = QString::number( numSpin->value() );

comPort = "COM" + comPort;

emit newCOM(comPort);

this->close();

}

void addCOMDialog::closeEvent(QCloseEvent *event)

{

emit finishNewCOM();

}

/*void addCOMDialog::acceptCliked()

{

emit finishNewCOM();

}*/G_H




202

PLIEGO DE CONDICIONES DISEÑO DE UNA APLICACIÓN PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60


203

DOCUMENTO 4.

PLANOS










204

0. ÍNDICE DE PLANOS




205

PLIEGO DE CONDICIONES DISEÑO DE UNA APLICACIÓN PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60


206

DOCUMENTO 5.

PLIEGO DE

CONDICIONES










207

1. ÍNDICE DEL PLIEGO DE CONDICIONES

DOCUMENTO 2. .................................................................................................. MEMORIA 7



2. OBJETO ......................................................................................................................................................... 11

3. ALCANCE...................................................................................................................................................... 12

4. ANTECEDENTES ......................................................................................................................................... 15



















9.5 LIBRERÍAS DE DESARROLLO ESPECÍFICAS ............................................................................................. 38




208

9.5.1 Librería de interfaz de usuario Qt ....................................................................................................... 38 9.5.2 Librería QExtSerialPort para el manejo del puerto serie ................................................................... 39 9.5.3 Librería gráfica 3D OpenSceneGraph ................................................................................................ 40







209

2. ESPECIFICACIONES DE MATERIALES Y

ELEMENTOS CONSTITUTIVOS DEL OBJETO

DEL PROYECTO

2.1 LISTADO DE MATERIALES EMPLEADOS

2.1.1 Hardware

Robot PUMA Staübli Rx-60

Controlador CS7

Cable de conexión serie RS-232

PC con procesador GHz , 2Gb RAM, 40 Gb disco duro, 16 MB de vídeo

2.1.2 Software

Visual Studio C++ 2008 Profesional

Librería Qt 4.8

Librería QtExtSerialPort 1.2

Librería OpenSceneGraph 3.0

2.2 REQUISITOS

2.2.1 Requisitos de hardware

PC con un puerto serie libre, 512 MB RAM, tarjeta gráfica 64 MB de video

Monitor de resolución mínima 1024x768

2.2.2 Requisitos de software

Windows XP

ESTADO DE MEDICIONES DISEÑO DE UNA APLICACIÓN PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60


211

DOCUMENTO 6.

ESTADO DE

MEDICIONES







PRESUPUESTO DISEÑO DE UNA APLICACIÓN PARA LA MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60


213

0. ÍNDICE DEL ESTADO DE MEDICIONES

DOCUMENTO 6. ................................................................ ESTADO DE MEDICIONES 211

0. ÍNDICE DEL ESTADO DE MEDICIONES ............................................................................................. 213

1. LISTADO DE PARTIDAS DE OBRA ....................................................................................................... 214

1.1 DESARROLLO DEL SOFTWARE DE MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60 214 1.1.1 Cuadro de precios 1.1.1 (software) ................................................................................................... 214 1.1.2 Cuadro de precios 1.1.2 (horas de trabajo) ...................................................................................... 214

1.2 COMPONENTES HARDWARE .............................................................................................................. 215 1.2.1 Cuadro de precios 1.2.1 .................................................................................................................... 215




214

1. LISTADO DE PARTIDAS DE OBRA

1.1 DESARROLLO DEL SOFTWARE DE MONITORIZACIÓN Y

SIMULACIÓN DEL ROBOT STAÜBLI RX-60

1.1.1 Cuadro de precios 1.1.1 (software)

Código Descripción Precio en letra Precio

(€)

1.1.1-00 Visual Studio C++ 2008 Profesional Cuatrocientos dieciséis euros 416,00

1.1.1-01 Modelos 3D del robot Staübli RX60 Cero euros 0,00

1.1.1-02 Software conversor de modelos 3D

Okino Polytrans

Trescientos noventa y cinco

euros 395,00

1.1.1-03 Librería Qt Cero euros 0,00

1.1.1-04 Librería QExtSerialPort Cero euros 0,00

1.1.1-05 Librería OpenSceneGraph Cero euros 0,00

1.1.1-06 Librería wwWidgets Cero euros 0,00

Tabla 11 Cuafro precios software

1.1.2 Cuadro de precios 1.1.2 (horas de trabajo)

Código Descripción Precio en letra Precio

(€)

1.1.2-00 Estudio de C++ Treinta euros / hora 30,00

1.1.2-01 Análisis de herramientas para

programar Treinta euros / hora 30,00

1.1.2-02 Análisis de librerías gráficas Treinta euros / hora 30,00

1.1.2-03 Análisis de software de robótica Treinta euros / hora 30,00

1.1.2-04 Estudio de OpenSceneGraph Treinta euros / hora 30,00

1.1.2-05 Estudio de Qt Treinta euros / hora 30,00

1.1.2-06 Cálculos Treinta euros / hora 30,00

1.1.2-07 Desarrollo de la aplicación Treinta euros / hora 30,00

1.1.2-08 Pruebas de la aplicación Treinta euros / hora 30,00

1.1.2-09 Redacción de la documentación Treinta euros / hora 30,00




215

Tabla 12 Cuadro de precios horas trabajadas

1.2 COMPONENTES HARDWARE

1.2.1 Cuadro de precios 1.2.1

Código Descripción Precio en letra Precio (€)

1.2.1-00 PC con 1 puerto serie Seiscientos euros 500,00

1.2.1-01 Cable de conexión RS-232 Ocho euros 8,00

Tabla 13 Cuadro de precios hardware




216

DOCUMENTO 7.

PRESUPUESTO










217

0 ÍNDICE DEL PRESUPUESTO

DOCUMENTO 7.PRESUPUESTO .................................................................................... 216

0 ÍNDICE DEL PRESUPUESTO .................................................................................................................. 217

1 PRESUPUESTO .......................................................................................................................................... 218

1.1 DESARROLLO DEL SOFTWARE DE MONITORIZACIÓN Y SIMULACIÓN DEL ROBOT STAÜBLI RX-60 ....... 218 1.1.1 Presupuesto 1.1.1 (software) ............................................................................................................. 218 1.1.2 Presupuesto 1.1.2 (horas de trabajo) ................................................................................................ 218

1.2 COMPONENTES HARDWARE ................................................................................................................ 219 1.2.1 Presupuesto 2.1.1 ............................................................................................................................... 219

2. RESUMEN DEL PRESUPUESTO ............................................................................................................ 220




218

1 PRESUPUESTO

1.1 DESARROLLO DEL SOFTWARE DE MONITORIZACIÓN Y

SIMULACIÓN DEL ROBOT STAÜBLI RX-60

1.1.1 Presupuesto 1.1.1 (software)

Código Designación de la unidad Medición

(uds.)

Precio unitario

(€) Presupuesto (€)

1.1.1-00 Visual Studio C++ 2008

Profesional 1 416,00 416,00

1.1.1-01 Modelos 3D del robot Staübli

RX60 1 0,00 0,00

1.1.1-02 Software conversor de

modelos 3D Okino Polytrans 1 395,00 395,00

1.1.1-03 Librería Qt 1 0,00 0,00

1.1.1-04 Librería QExtSerialPort 1 0,00 0,00

1.1.1-05 Librería OpenSceneGraph 1 0,00 0,00

1.1.1-06 Librería wwWidgets 1 0,00 0,00

Tabla 14 Presupuesto software

1.1.2 Presupuesto 1.1.2 (horas de trabajo)


(uds.)

Precio unitario


1.1.2-00 Estudio de C++ 180 30,00 5.400,00

1.1.2-01 Análisis de herramientas para

programar 90 30,00 2.700,00

1.1.2-02 Análisis de librerías gráficas 90 30,00 2.700,00

1.1.2-03 Análisis de software de

robótica 90 30,00 2.700,00

1.1.2-04 Estudio de OpenSceneGraph 180 30,00 5.400,00

1.1.2-05 Estudio de Qt 180 30,00 5.400,00

1.1.2-06 Cálculos 24 30,00 720,00




219

1.1.2-07 Desarrollo de la aplicación 675 30,00 20.250,00

1.1.2-08 Pruebas de la aplicación 90 30,00 2.700,00

1.1.2-09 Redacción de la

documentación 150 30,00 4.500,00

Tabla 15 Presupuesto horas trabajadas

1.2 COMPONENTES HARDWARE

1.2.1 Presupuesto 2.1.1


(uds.)

Precio unitario


1.2.1-00 PC con 1 puerto serie 1 500,00

1.2.1-01 Cable de conexión RS-232 1 8,00

Tabla 16 Presupuesto hardware




220

2. RESUMEN DEL PRESUPUESTO

TOTAL PRESUPUESTO DE EJECUCIÓN MATERIAL ............. 53789,00 €

GASTOS GENERALES (13%) ..................................... 6992,57 €

BENEFICIO INDUSTRIAL (6%)................................... 3227,34 €

TOTAL PARCIAL ............................................................. 64008,91 €

I.V.A. (21%) .................................................................. 13441,87 €

TOTAL PRESUPUESTO EJECUCIÓN POR CONTRATA ......... 77450,78 €

________________________________________________________________

El presente presupuesto asciende a la cantidad de:

SETENTA Y CUATRO MIL CUATROCIENTOS CINCUENTA EUROS CON DETENTA

Y OCHO CÉNTIMOS

Logroño, 31 de Enero de 2013

EL INGENIERO AUTOR





221

Escalas:

DibujadoFECHA

U.N.E. Tolerancia general

NOMBRE ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INDUSTRIAL

Universidad de la Rioja

Ingeniería Técnica Industrial especialidad en Electrónica Industrial

Sustituye a:Sustituido por:

28-01-2013 Carlos Elvira Izurrategui

Francisco Ochoa Bueno08-01-2013

Diseño de una aplicación de uso didáctico para lasimulación y monitorización del robot Staübli RX-60

Código de referencia:

Número de plano: 1

Dimensiones del robot Staübli RX-60

1:10

Diseño de una aplicación didáctica para la monitorización ...DISEÑO DE UNA APLICACIÓN PARA LA...

Documents

Transcript of Diseño de una aplicación didáctica para la monitorización ...DISEÑO DE UNA APLICACIÓN PARA LA...