R 000001562

PROYECTO FIN DE CARRERA
Título
Diseño de una aplicación didáctica para la monitorización

y simulación del robot STAÜBLI RX-60
Autor/es
Francisco Ochoa Bueno
Director/es
Carlos Elvira Izurrategui

Facultad
Titulación
Proyecto Fin de Carrera
Departamento
Ingeniería Eléctrica
Curso Académico
2012-2013
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 la
Universidad 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.
© El autor
© Universidad de La Rioja, Servicio de Publicaciones, 2013
publicaciones.unirioja.es
E-mail: publicaciones@unirioja.es
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

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.
Enero 2013 Ingeniería Técnica Industrial Electrónica - Universidad de La Rioja I

Palabras Clave
 Robot
 Cinemática
 Cadena cinemática
 Conexión serie RS232
 Interfaz de usuario
 Librería gráfica 3D
 Simulación
Enero 2013 Ingeniería Técnica Industrial Electrónica - Universidad de La Rioja II

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”
Enero 2013 Ingeniería Técnica Industrial Electrónica - Universidad de La Rioja 1

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.3 TIPO DE CONEXIÓN ............................................................................................................................... 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.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

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

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.1 Presupuesto 1.1.1 (software) ............................................................................................................. 218
1.1.2 Presupuesto 1.1.2 (horas de trabajo) ................................................................................................ 218
1.2.1 Presupuesto 2.1.1............................................................................................................................... 219
2. RESUMEN DEL PRESUPUESTO ............................................................................................................ 220

MEMORIA
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

MEMORIA
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

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

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

MEMORIA
UNIVERSIDAD DE LA RIOJA
ESCUELA DE INGENIERÍA INDUSTRIAL
TÍTULO
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: carlos.elvira@unirioja.es
AUTOR
FRANCISCO OCHOA BUENO
Titulación: Ingeniería Técnica Industrial especialidad en Electrónica Industrial

DNI: 16610968-T
Correo electrónico: francisco.ochoa@alum.unirioja.es
Logroño a 31 de Enero de 2013
Firma del Autor del Proyecto:

MEMORIA
1. ÍNDICES DE MEMORIA
1.1 ÍNDICE DE CONTENIDO
DOCUMENTO 2. MEMORIA ......................................................................................................................... 7
2. OBJETO ......................................................................................................................................................... 11
3. ALCANCE...................................................................................................................................................... 12
4. ANTECEDENTES ......................................................................................................................................... 15
5.2 BIBLIOGRAFÍA ...................................................................................................................................... 16
5.2.2 Páginas web ......................................................................................................................................... 16
6.1 DEFINICIONES ....................................................................................................................................... 18
6.2 ABREVIATURAS .................................................................................................................................... 18
8.2 COMPILADOR ........................................................................................................................................ 22
8.3 TIPO DE CONEXIÓN ............................................................................................................................... 23
9.1 INTRODUCCIÓN ..................................................................................................................................... 27
Enero 2013 Ingeniería Técnica Industrial

9 Electrónica
MEMORIA
9.6.1 Introducción ......................................................................................................................................... 41
DOCUMENTO 3. ANEXOS ........................................................................................................................... 63

MEMORIA
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.

MEMORIA
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.

MEMORIA
 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

MEMORIA
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.

MEMORIA
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.

MEMORIA
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

MEMORIA
[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

MEMORIA
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

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
 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.

MEMORIA

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.

MEMORIA
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

MEMORIA
8.5.2 Tabla comparativa
OPENGL
CARACTERÍSTICAS JAVA 3D OGRE OPEN INVENTOR OPENSG OPENSCENEGRAPH
PERFORMER
Sí. Windows, Linux, IRIX, FreeBSD,
Sí (se ejecuta en Sí. Windows, Linux , Sí. Windows, Linux,
Multiplataforma IRIX, Linux, Windows IRIX, Linux, Windows Mac, Solaris, HP-Ux, AIX,
navegador) Mac Solaris, Mac
Playstation 2
Comercial (primeras
Licencia Libre GPLv2 Libre MIT Comercial Libre LGPL Libre LGPL
versiones LGPL)
Eficiencia Alta Media Óptima Media Muy Alta Muy Alta
Facilidad de uso Alta Media Baja Alta Alta Alta

C++
Lenguaje que usa Java No oficiales: Python, C, C++ C++, .NET, Java C++ C++, Lua, Java, Python
Java, .NET
API que usa OpenGL / Direct3D OpenGL / Direct3D OpenGL OpenGL OpenGL OpenGL
Multiproceso Sí Sí Sí, avanzado No Sí. Sí

Funcionamiento en Existe un proyecto, pero
Sí No No Sí, mediante plugin Sí, mediante plugin
navegador no es estable
- Controles de interacción
- LOD
- Configuraciones de usuario con los objetos
- Shaders - Gestión prioridad de
multipantalla - Mecanismos muy Admite distribución LOD
- Mallas avanzadas objetos de la escena
Opciones avanzadas - Sonido 3D flexibles de descripción de entre varias estaciones Culling de distintos tipos
- Animaciones tipo - Especializada en
- Shaders programables objetos de trabajo. Escalabilidad
esqueleto multiprocesamiento
- Realidad virtual - Capacidades de
- Trayectorias
renderizado avanzadas
Sí. Diseñada para
Sí. Admite plugins de
Extensiones No No Sí adaptarse a los Sí
forma fácil.
usuarios.
XML, ZIP, PK3
Formato propio.
Y varios formatos OpenInventor,
CAD, VRML, X3D, OBJ, Formato propio y Permite importer muchos otros(
Archivos que admite típicos de imagen OpenFlight, Designer’s Formato propio
3DS VRML VRML, OBJ, DXF, 3DS,
Tiene varios formatos Worbench, Medit, OBJ
COLLADA, LWO, etc. )
propios
- Muy buena - Documentación escasa, pero tiene
- Buena documentación.
documentación. Hay unos pocos libros y en abundantes ejemplos bastante
- Existen bastantes libros. No hay mucha
Documentación - Hay algunos libros su web existe bastante Algo escasa. buenos.
- Foro no muy activo información
con ejemplos. información. - Hay algunos libros prácticos.
aunque existen otros.
- Foro muy activo. - Foro muy activo.
Tabla 1 Comparación de distintas librerías 3D
MEMORIA

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.
26 Ingeniería Técnica Industrial Electrónica - Universidad de La Rioja Enero 2013

MEMORIA
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:

MEMORIA
Figura 2 Arquitectura general del sistema utilizado en el proyecto

MEMORIA
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.

MEMORIA
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

MEMORIA
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.

MEMORIA
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.

MEMORIA
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
A B C D E F
Distribución del rango +120.5 /
+/-127.5 +/-134.5 +/-270 +/-270
de trabajo [º] +/-160 -109.5
Velocidad Nominal
287 287 319 410 320 700
[º/s]
Resolución angular
0.724 0.724 0.806 1.177 0.879 2.747
[º·10-3]
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

MEMORIA
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 ).

MEMORIA
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.

MEMORIA
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.

MEMORIA
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
Habilita el brazo para poder usarlo. A continuación hay que
enable power
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}.
Permite definir un punto utilizando ángulos de articulación
point #a
{Jt1…Jt6}.
Permite definir la velocidad de sistema como porcentaje de la
speed %vel
velocidad máxima.
do ready Desplaza cada miembro del brazo a su posición de reposo.
Desplaza el miembro eje el número de grados indicado en grad
do drive eje,
al porcentaje de velocidad indicado en vel referido a la
Dgrad,% vel
velocidad de sistema.
do move a Desplaza el brazo a la posición indicada en el punto a, definido a

MEMORIA
través de coordenadas de posición/orientación cartesianas.
Desplaza el brazo a la posición indicada en el punto #a, definido
do move #a
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).

MEMORIA
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.

MEMORIA
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.

MEMORIA
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

MEMORIA
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

MEMORIA
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

MEMORIA
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.

MEMORIA
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

MEMORIA
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).

MEMORIA
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:

MEMORIA
Articulación \
theta (º) d (mm) a (mm) alpha (º)
Parámetro
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

MEMORIA
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

MEMORIA
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.

MEMORIA
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

MEMORIA
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.

MEMORIA
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).

MEMORIA
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

MEMORIA
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

MEMORIA
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

MEMORIA
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

MEMORIA
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.

MEMORIA
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).

MEMORIA
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…

MEMORIA
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.
DURACIÓN
CÓDIGO DEPENDENCIA DESCRIPCIÓN DE LA ACTIVIDAD
(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

MEMORIA
Figura 31Diagrama de Gantt del proyecto

DOCUMENTO 2.
PLANOS
DOCUMENTO 3.
ANEXOS
Enero 2013 Ingeniería Técnica Industrial Electrónica
MEMORIA
“DISEÑO DE UNA APLICACIÓN DIDÁCTICA PARA LA MONITORIZACIÓN Y

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

MEMORIA
0. ÍNDICE DE ANEXOS
DOCUMENTO 3. ...................................................................................................... ANEXOS ¡ERROR!
0. ÍNDICE DE ANEXOS .................................................................... ¡ERROR! MARCADOR NO DEFINIDO.
1. ANEXO I – ESTUDIO DE LIBRERÍAS GRÁFICAS EXISTENTES EN EL MERCADO¡ERROR! MARCADOR NO
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
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.

MEMORIA
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.

MEMORIA
 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.

MEMORIA
 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.

MEMORIA
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.

MEMORIA
 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:

MEMORIA
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.

MEMORIA
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.

MEMORIA
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

MEMORIA
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.

MEMORIA
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.
 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

MEMORIA
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”.

MEMORIA
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

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
 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.

MEMORIA
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.

MEMORIA
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)

MEMORIA
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.

MEMORIA
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

MEMORIA
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.

MEMORIA
 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.

MEMORIA
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ó.

MEMORIA
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).

MEMORIA
 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.
 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.

MEMORIA
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

MEMORIA
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.
 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

MEMORIA
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ú

MEMORIA
 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.

MEMORIA
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

MEMORIA
 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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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

MEMORIA
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

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
 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.

MEMORIA
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.

MEMORIA
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.

MEMORIA
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

MEMORIA
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

MEMORIA
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

MEMORIA
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).

MEMORIA
3.2 APLICACIONES DE MONITORIZACIÓN Y SIMULACIÓN

EDUCATIVAS EXISTENTES
3.2.1 RoboAnalyzer
3.2.2 RoboUALab

MEMORIA
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);

MEMORIA
};
#endif // VENTANAPRINCIPAL_H

MEMORIA
VENTANA PRINCIPAL.H
// CABECERAS
//---------------------------------------------------------------------
namespace Ui {
}

//---------------------------------------------------------------------
{
Q_OBJECT
public:
private:
void _crearMenus();
public slots:
};

MEMORIA
VENTANA PRINCIPAL.CPP
// CABECERAS
//---------------------------------------------------------------------
namespace Ui {
}

//---------------------------------------------------------------------
{
Q_OBJECT
public:
private:
void _crearMenus();
public slots:
};

MEMORIA
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();
}

MEMORIA
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;

MEMORIA
//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

MEMORIA
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

MEMORIA
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)

MEMORIA
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" );

MEMORIA
//-----------------------------------------------------------------
---
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,

MEMORIA
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);


MEMORIA




//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 );

MEMORIA

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 );

MEMORIA
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

MEMORIA
//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(
}

MEMORIA
{

6.31f );
}
{

7.41f );
}
{

9.41f );
}
{

10.06f );
}

MEMORIA
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();

MEMORIA
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 );

MEMORIA
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,

MEMORIA
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);

MEMORIA
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,

MEMORIA
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));

MEMORIA
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);

MEMORIA
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:
}

MEMORIA
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)

MEMORIA
/*
*/
//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" );

MEMORIA
//-----------------------------------------------------------------
---
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,

MEMORIA
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


MEMORIA




//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 );

MEMORIA

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 );

MEMORIA
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

MEMORIA
//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 );
}

MEMORIA
{

6.31f );
}
{

7.41f );
}
{

9.41f );
}
{

10.06f );
}

MEMORIA
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()
{

MEMORIA
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 );

MEMORIA
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,

MEMORIA
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;

MEMORIA
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,

MEMORIA
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));

MEMORIA
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);

MEMORIA
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:
}

MEMORIA
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 -->???

MEMORIA
//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

MEMORIA
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;

MEMORIA
/*
//.......................................................................
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();

MEMORIA
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);

MEMORIA
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 )

MEMORIA
{
// 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

MEMORIA
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 ???
}

MEMORIA
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();

MEMORIA
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

MEMORIA
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...");

MEMORIA
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) );

MEMORIA
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;

MEMORIA
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;
}

MEMORIA
else if ( eventoTeclado->key() == Qt::Key_Down ) {
message->redo();
if ( message->text() == "" ) {
message->redo();
}
return true;
}
}
}
return false;
}

MEMORIA
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();

MEMORIA
};
#endif

MEMORIA
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()) );

MEMORIA
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

MEMORIA
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(),

MEMORIA
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.") );
}

MEMORIA
void panelPrograma::finalizarTiempo()
{
finTiempo = true;
//qDebug() << "FIN DEL TIEEEEEEEEEEEEEEEEEEEEEEEEEMPO";
}
void panelPrograma::panelConfig()
{
void panelPrograma::cambiarFuente()
{

MEMORIA
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

MEMORIA
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()));

MEMORIA
//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

MEMORIA
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();
}

MEMORIA
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";

MEMORIA

MEMORIA
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.
*/

MEMORIA
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_*/

MEMORIA
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>
==============

MEMORIA
*/
/*
==============
<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,

MEMORIA
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;
}

MEMORIA
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

MEMORIA
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;

MEMORIA
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();
}

MEMORIA
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;
};

MEMORIA
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);

MEMORIA
}
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(),

MEMORIA
Qt::AlignRight, number);
}
block = block.next();
top = bottom;
bottom = top + (int) blockBoundingRect(block).height();
++blockNumber;
}
}

MEMORIA
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

MEMORIA
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

MEMORIA

PLIEGO DE CONDICIONES
DOCUMENTO 4.
PLANOS


MEMORIA
0. ÍNDICE DE PLANOS

MEMORIA

PLIEGO DE CONDICIONES
DOCUMENTO 5.
PLIEGO DE
CONDICIONES


MEMORIA
1. ÍNDICE DEL PLIEGO DE CONDICIONES

DOCUMENTO 2. .................................................................................................. MEMORIA 7
2. OBJETO ......................................................................................................................................................... 11
3. ALCANCE...................................................................................................................................................... 12
4. ANTECEDENTES ......................................................................................................................................... 15
5.2 BIBLIOGRAFÍA ...................................................................................................................................... 16
5.2.2 Páginas web ......................................................................................................................................... 16
6.1 DEFINICIONES ....................................................................................................................................... 18
6.2 ABREVIATURAS .................................................................................................................................... 18
8.2 COMPILADOR ........................................................................................................................................ 22
8.3 TIPO DE CONEXIÓN ............................................................................................................................... 23
9.1 INTRODUCCIÓN ..................................................................................................................................... 27

MEMORIA
9.6.1 Introducción ......................................................................................................................................... 41

MEMORIA
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
DOCUMENTO 6.
ESTADO DE
MEDICIONES


PRESUPUESTO
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

MEMORIA
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)

Precio
Código Descripción Precio en letra
(€)
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
Software conversor de modelos 3D Trescientos noventa y cinco
1.1.1-02 395,00
Okino Polytrans euros
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)

Precio
Código Descripción Precio en letra
(€)
1.1.2-00 Estudio de C++ Treinta euros / hora 30,00
Análisis de herramientas para
1.1.2-01 Treinta euros / hora 30,00
programar
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

MEMORIA
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

MEMORIA
DOCUMENTO 7.
PRESUPUESTO


MEMORIA
0 ÍNDICE DEL PRESUPUESTO

DOCUMENTO 7.PRESUPUESTO .................................................................................... 216
0 ÍNDICE DEL PRESUPUESTO .................................................................................................................. 217
1 PRESUPUESTO .......................................................................................................................................... 218
1.1.1 Presupuesto 1.1.1 (software) ............................................................................................................. 218
1.1.2 Presupuesto 1.1.2 (horas de trabajo) ................................................................................................ 218
1.2.1 Presupuesto 2.1.1............................................................................................................................... 219
2. RESUMEN DEL PRESUPUESTO ............................................................................................................ 220

MEMORIA
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)

Medición Precio unitario
Código Designación de la unidad Presupuesto (€)
(uds.) (€)
Visual Studio C++ 2008
1.1.1-00 1 416,00 416,00
Profesional
Modelos 3D del robot Staübli
1.1.1-01 1 0,00 0,00
RX60
Software conversor de
1.1.1-02 1 395,00 395,00
modelos 3D Okino Polytrans
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.) (€)
1.1.2-00 Estudio de C++ 180 30,00 5.400,00
Análisis de herramientas para
1.1.2-01 90 30,00 2.700,00
programar
1.1.2-02 Análisis de librerías gráficas 90 30,00 2.700,00
Análisis de software de
1.1.2-03 90 30,00 2.700,00
robótica
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

MEMORIA
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

Redacción de la
1.1.2-09 150 30,00 4.500,00
documentación
Tabla 15 Presupuesto horas trabajadas
1.2 COMPONENTES HARDWARE
1.2.1 Presupuesto 2.1.1

(uds.) (€)
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

MEMORIA
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

MEMORIA

FECHA NOMBRE ESCUELA TÉCNICA SUPERIOR DE
Dibujado 08-01-2013 Francisco Ochoa Bueno INGENIERÍA INDUSTRIAL
Universidad de la Rioja
28-01-2013 Carlos Elvira Izurrategui
U.N.E. Tolerancia general Ingeniería Técnica Industrial especialidad en Electrónica Industrial
Escalas: Diseño de una aplicación de uso didáctico para la Código de referencia:

1:10 simulación y monitorización del robot Staübli RX-60
Número de plano: 1
Dimensiones del robot Staübli RX-60 Sustituye a:

Sustituido por:

R 000001562

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

R 000001562

Uploaded by

Copyright:

Available Formats

PROYECTO FIN DE CARRERA

Diseño de una aplicación didáctica para la monitorización

Francisco Ochoa Bueno

Carlos Elvira Izurrategui

Proyecto Fin de Carrera

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INDUSTRIAL

PROYECTO FIN DE CARRERA

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

DIRECTOR: CARLOS ELVIRA IZURRATEGUI

AUTOR: FRANCISO OCHOA BUENO

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

FECHA: 31 de Enero de 2013

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

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

 Conexión serie RS232

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

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

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 1

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

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

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

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

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

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

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

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

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

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

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

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 7

PROYECTO FIN DE CARRERA

ESCUELA PARA LA QUE SE REDACTA

Correo electrónico: carlos.elvira@unirioja.es

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

Logroño a 31 de Enero de 2013

Firma del Autor del Proyecto:

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

Enero 2013 Ingeniería Técnica Industrial

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

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

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

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

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

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

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

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

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

o Describir sus características.

o Realizar una comparación entre ellas.

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

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

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

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.