3 diseÑo e implementacion del simuladorbibing.us.es/proyectos/abreproy/12094/fichero/3... · 3...

3 DISEÑO E IMPLEMENTACION DEL SIMULADOR


3.1 MOTOR FÍSICO Y SISTEMA DE COLISIONES

La simulación de la física se hace indispensable para visualización de un entorno donde existenobjetos que se mueven e interaccionan con otros. La simulación de la física es una disciplina muyamplia, este trabajo se centra principalmente en la física de objetos rígidos. Debido a que setrabajará en un entorno en 3D se tendrán vectores con tres componentes que permitirán manejarlo más básico de la física para objetos rígidos tales como posiciones, aceleraciones, fuerzas, etc.En (1) se muestran vectores de posición y velocidad. Los motores físicos parten de las leyes demovimiento de Newton, que describen el comportamiento de una masa puntual. La primera leyde Newton expresa que un objeto con velocidad uniforme, sobre el cual no existen fuerzas, nocambiará su velocidad. Aunque en el mundo real siempre existe algún tipo de fuerza que sufrenlos objetos en movimiento, como la producida por rozamiento. La segunda ley de Newton es laque relaciona la fuerza con aceleración.

p =

px

py

pz

v =

vx

vy

vz

(1)

F = ma = mp̈ (2)

p̈ = 1mF (3)

En el motor físico se obtendrá la aceleración de un objeto a partir de la fuerza que se le estéaplicando (3). Mediante integración se podrá conocer la velocidad y la aceleración. Los objetos,por tanto, poseerán las cuatro características básicas que son velocidad, aceleración, fuerza y masa.Además de las leyes de Newton, se debe simular la interacción de objetos y fuerzas. Por ejemplo,la fuerza de la gravedad estará presente en cualquier entorno de simulación. Normalmente, sesimulará la fuerza de gravedad de la tierra, por lo que se aplicará (5). Donde se aproximará laconstante g con un valor de 9,8 m

s2 ,10,0 ms2 , para realizar cálculos rápidos [7].

F = Gm1m2

r2 (4)

F = mg (5)

La aceleración de la gravedad que se aplicará a los objetos será por tanto, un vector.

g =

0−g0

F =

Fx

Fy

Fz

(6)

Los objetos podrán estar tanto en reposo como en movimiento. En movimiento cualquier objetosufre rozamiento. La fuerza de rozamiento viene dada por la ecuación (7), donde Fr es la fuerzade rozamiento, N la normal y µ el coeficiente de rozamiento. Aunque se deben tener en cuenta losdos tipos de coeficientes de rozamiento, el estático y el dinámico µs y µk. Estos coeficientes soncaracterísticos para cada par de materiales que se encuentran en conctacto y dependen de otrosfactores como la temperatura. Una opción sería usar valores aproximados para ciertos materiales,como los extraídos de [7] que se muestran en la tabla 1.

Fr = µN (7)

Simulador para control y automatización. 24 de 86


Material 1 Material 2 µs µk

Steel Steel 0.74 0.57Aluminium Steel 0.61 0.47Copper Steel 0.53 0.36Rubber Concrete 1 0.8Wood Wood 0.25-0.5 0.2Glass Glass 0.94 0.4

Waxed wood Wet snow 0.14 0.1Waxed wood Dry snow - 0.04

Metal Metal 0.15 0.06Ice Ice 0.1 0.03

Teflon Teflon 0.04 0.04Synovial Jointsin Humans

- 0.01 0.003

Table 1: Valores aproximados de los coeficientes de rozamiento dinámico µk y estático µs. Paresde materiales en contacto.

Otro aspecto importante a tener en cuenta para la simulación de objetos rígidos será el momentode inercia de un objeto de masa uniforme, el cual viene dado por (8). Para la simulación se haráuso de los tensores de inercia de un sólido rígidoIxx, Iyy e Izz y los productos de inercia Ixy, Ixz eIzy.

I =ˆ

V

ρr2dV (8)

Para procesar todas las fuerzas que están actuando sobre un mismo objeto en el simulador seutilizará el principio de DÁlambert. Este principio implica que si, en un sistema de partículas,se tiene un objeto sobre el cual actúan una serie de fuerzas, se puede obtener una única fuerza apartir del conjunto de fuerzas [4]. Se hará la suma vectorial de fuerzas a las que está sometidoun objeto para obtener una única fuerza total, ver (9). Otras características como el centro demasas, orientación (ángulos de Euler), momentos de inercia y de fuerza o par deberán aplicarsepara conseguir realismo en la simulación.

F =∑

i

Fi (9)

Para el desarrollo de la aplicación se ha utilizado un motor físico de propósito general. Sebuscaba un motor que fuera gratuito y de código libre que además incluyera las característicasmás básicas de la física que se han comentado para poder realizar la simulación de objetos rígidos.De esta forma no habría problema en añadir nuevas propiedades físicas en futuras mejoras de laaplicación.

Motores físicos que cumplen con estas condiciones son:

• JigLibX

• Jitter

• Bullet Physics



Figure 8: Ejemplos de uso de Bullet Physics.

Figure 9: Ejemplos de uso de JigLibX.

Dado que los motores encontrados tenían las características necesarias y todos eran muysimilares como para hacer una elección y dado que no se disponía de tiempo para realizar unexamen exhaustivo del código para hacer la elección del idóneo se escogío JigLibx tras ver algunasde las simulaciones realizadas con el mismo.

Como muchas otras librerías en C#, JigLibx es una librería portada a C# desde C++, JigLib.Aunque el objetivo principal de JigLibX Beta es conesguir que la librería se “más” .NET. Comoestá completamente escrita en C# es particularmente ajustable a su uso con XNA. El motor físicoposee un sistema de colisiones, física de objetos rígidos y es gratuito y de código abierto. Por loque se integrará bien en la aplicación de la que es objeto este proyecto.

El sistema de colisiones que implementa JigLibX está basado en profundidad de penetración.El sistema de colisiónes es la parte del simulador encargada de detectar si se ha producido unacolisión entre objetos, cómo ha sido y qué consecuencias conlleva. En base al trabajo del sistemade colisiones se podrán realizar las tareas de aplicación de ecuaciones físicas a los objetos.

La colisión entre objetos ocurre cuando existe un contacto entre éstos. Dado que se tiene unsistema de simulación en 3D y por tanto objetos modelados en base a polígonos, se debe hacerdistinción entre colisiones punto-punto, arista-arista, arista-cara, cara-cara. Uno de los problemasal desarrollar el sistema de colisiones es el tiempo de ejecución. En la vida real dos objetos chocan,



pero en una simulación de ordenador debido a que el tiempo es tratado de forma discreta, lo queocurrirá es que penetrarán el uno en el otro, ver figura 10. Esto se resolvería separando los objetosen direcciones opuestas a las que tenían inicialmente hasta que dejen de tocarse.

Figura 10: Contacto entre 2 objetos penetrando

Uno de los métodos más utilizados se denomina penalty-based method, donde usa laprofundidad de penetración definida como la distancia de traslación mínima requerida para separardos objetos en intersección [2]. En este método se permite la interpenetración entre objetos y pararealizar la separación se opta por aplicar fuerzas proporcionales a la cantidad de penetración. Alresolver la colisión se tendrán en cuenta todas las magnitudes de los objetos involucrados, velocidadlineal, angular, fuerzas etc. Al producirse en una colisión entre dos objetos debe cumplirse elprincipio de conservación en el momento del choque y que viene expresado por (10). Dos objetos avelocidades de choque va y vb , con masas ma y mb, tras el choque adquirirán una nueva velocidaden otras direcciones y sentidos. La conservación ocurrirá en el momento justo del choque, tras elcual el movimiento de los objetos deberá responder al resto de fuerzas externas como la fuerza derozamiento.

mava +mbvb = mav′a +mbv

′b (10)

El sistema de colisiones deberá comprobar si existen colisiones entre cada par de objetos delsimulador. Comprobar una colisión supone conocer la geometría de cada objeto y obtener todoslos puntos de colisión existentes entre dos objetos. Si existen muchos objetos, esta comprobaciónpuede consumir demasiado tiempo de procesado y ralentizar la simulación. Una solución a esteproblema es utilizar dos tipos de detectores de colisiones. El primero de ellos haría una localizaciónde los objetos con posibilidad de contacto sin entrar en detalles. El segundo recibiría la lista deobjetos y realizaría un chequeo más exacto hallando las colisiones y la información necesaria paraque sean tratadas por el motor físico. De las posibles colisiones también se eliminarían aquellascolisiones que se producen entre un par de objetos que no poseen velocidad alguna y se encuentranen reposo. Es decir, sólo se tendrán en cuentan las posibles colisiones entre objetos reposo-activoy activo-activo [5].

En general se debe introducir en el sistema un conjunto básico de figuras geométricas ya quelos cuerpo físicos tendrán una forma que será una figura geométrica o en casos más complejos unacombinación. En la figura 11 se pueden observar ambos casos. Entre las formas básicas destacanel cubo, cilindro y esfera. Con estas tres se podría modelar cualquier objeto de forma aproximada.



a) b)

Figura 11: Objetos con composición geométrica simple a), y compuesta b).

Como se ha comentado anteriormente, se usarán modelos de objetos rígidos, es decir, nodeformables. El uso de este tipo de objetos, no realistas, presenta algunas desventajas. En primerlugar en la simulación de un choque entre dos objetos nuncan se dará una amortiguación pordeformación. Aún así la elasticidad se puede incluir en el modelo mediante un coeficiente juntocon los coeficientes de rozamiento, como se ha comentado anteriormente. En segundo lugar el usode modelos mecánicos basados en objetos rígidos provoca que las velocidades sean discontinuas[8]. El uso de este modelo más simple está justificado ya que un modelo más completo conconsideraciones de elasticidad del material consumiría demasiado tiempo de procesador y daríalugar a una renderización ralentizada y, por tanto, una simulación inapropiada.

El proyecto JigLibX en Visual Express C# está formado por los siguientes elementos:

Figura 12: Estructura del proyecto JigLibX en Visual Express C#.

3.2 ESTRUCTURA DE LA APLICACIÓN

Como muchas aplicaciones, se basa en un bucle infinito que el usuario deberá poder ser capaz dedetener en cualquier momento. Al tratarse de una aplicación con renderizado en 3D se deberáactualizar el dibujado en pantalla en cada paso de ejecución. Los modelos 3D son parte delcontenido de la aplicación. Para ahorrar carga de trabajo, todos los modelos que serán necesarios



para la ejecución se cargarán al comienzo del programa. La estructura del programa está divididaen varios métodos, de los cuales algunos se ejecutarán una única vez, y otros en cada paso deejecución. La estructura es como sigue:

Figura 13: Estructura de la aplicación. Diagrama de flujo.

Figura 14: Estructura del proyecto de la aplicación en Visual Express C#.



3.3 PROGRAMA PRINCIPAL

El programa principal es la clase Simulador.cs, donde se encuentra la estructura principal delprograma comentada en el apartado anterior. Al empezar el proyecto se pretendía que fuerasencillo añadir nuevos elementos a medida que se fuesen desarrollando ahora o en un futuro. Quesea sencillo no implica que no haya que introducir código nuevo. No obstante la forma de introducirel nuevo código es sistemático de la forma que se ha desarrollado el programa principal.

Figura 15: Ejemplo de código en C# de la declaración de las variables para incluir mesas giratorias.

Al comienzo de la clase Simulador.cs se declaran todas las variables que se van a necesitar,así como las propias clases de elementos industriales que existen. En la figura 15 se muestra unaporción de código donde se observan las variables necesarias para introducir “5” cintas giratoriasen el simulador.

Figura 16: Código en C# de la carga de contenidos 3D.

Posteriormente, en el método LoadContent, se cargan todos los modelos 3D que dicha clase vaa necesitar, ver figura 16. En el método Initialize se inicializarán los parámetros necesarios básicosy son los siguientes, ver figura 17:

• Posición del elemento

• Nº de actuadores en el cuadro de actuadores

• Nº de sensores en el cuadro de sensores

Una vez que se tiene todo ésto, ya se puede empezar la ejecución de los métodos Update yDraw. En el método Update, se llamará mediante un bucle “for” al método Update de cada una delas Cintas transportadoras que existan en el escenario. De la misma manera, en el método Drawse llamará al método Draw de cada una de las cintas mediante un bucle “for”. De esta forma si sepretende añadir una nueva cinta, solo hay que aumentar el valor “num_Cintas2”, y copiar/pegarla porción de código de otra cinta cambiando sus parámetros de posición. Al aumentar el valor“num_Cintas2” ya se está incluyendo en los bucles “for” de los métodos Update y Draw la nuevacinta transportadora, luego el mecanismo de introducción de elementos es relativamente sencillo,ver figura 18.



Figura 17: Código C# de uso repetitivo para inicializar un elemento.

a)

b)

Figure 18: Código C# de la aplicación. a) Código repetitivo en bucle “for” para la actualizaciónde elementos de una misma clase. b) Código repetitivo para el renderizado de modelos 3D.

3.4 CLASES PARA LOS ELEMENTOS INDUSTRIALES

En este apartado se va a describir como se han desarrollado los elementos industriales para la plantapiloto en pruebas del simulador 3D. Cada una de ellas se encapsula en una clase con unos métodosobligatorios y otros opcionales como se ha descrito anteriormente. Ésto hará que el desarrollo denuevos elementos y su adición al programa principal sea más rápido, sencillo y seguro ante fallosde compilación y ejecución.

Cuando se habla de métodos opcionales, se está haciendo referencia a un método extra que esnecesario ejecutar una vez que el motor físico ha realizado su pasada, cosa que ocurre al final delmétodo Update del programa principal en “Simulador.cs”. Este método extra puede ser necesariopara truncar o mejorar el rendimiento del motor físico. Debido a que vamos a simular elementosmecánicos basados en objetos diferentes que interacturan entre sí pero que no están gobernadospor ninguna mécanica entre ellos más que la física clásica, la reorientación, ajuste de velocidadesy/o detección extra de colisiones pueden llegar a ser necesarios tras el paso de los objetos por elmotor físico. Así pues se deja esta opción en caso de ser necesitada, y se ejecutaría siempre al finaldel método Update de la clase “Simulador.cs”, después de la llamada al motor físico, ver figura 20.

La estructura de una clase será en general como se muestra en la siguiente figura:



Figura 19: Estructura de métodos de la clase Elemento Industrial.

Figura 20: Código en C# mostrando la llamada a métodos “Opcionales”, de las clases Grúa yCinta2, tras la llamada al motor físico.

3.4.1 CINTA TRANSPORTADORA

La cinta transportadora es el primer dispositivo industrial que se desarrolló y por lo tanto esel que más modificaciones ha sufrido. Debido a que fue el primer dispositivo, partes del códigode otros elementos están basados en ellas. Cuando se obtuvo una versión funcional de la cintatransportadora se pasó a diseñar nuevos dispositivos. No obstante a medida que se programabannuevos elementos se encontraban formas de optimizar tanto el código como el renderizado 3Dde las distintas partes que componen un dispositivo. Por lo cual se volvía siempre a la cintatransportadora para mejorarla tanto gráfica como computacionalmente.



Una vez que se había estudiado el motor físico y su comportamiento ya era posible comenzarcon el desarrollo de un dispositivo industrial muy común en las plantas industriales, la cintatransportadora. Aunque las cintas trasnportadoras las hay de muchos tipos y tamaños, la que seha diseñado es una cinta lineal rectilínea.

Dado que el motor físico integrado en la solución trabaja con cuerpos rígidos, la mejor opciónpara diseñar los dispositivos es basarlo en las figuras geométricas más básicas, cubo, esfera ycilindro. En base a estas tres figuras se desarrolla todo el modelo, tanto físico como 3D.

Al comenzar a diseñar un dispositivo es importante reducirlo a su más básico funcionamientopara que la implementación sea lo más sencilla y rápida posible. Es por eso que se ha tomadola cinta transportadora como “algo que mueve objetos de un punto a otro”. En este punto noimporta que exista un motor que proporciona la fuerza necesaria para que unos engranajes hagangirar unos rodillos que a su vez muevan una cinta, generalmente de materíal plastico o metálico,muevan los objetos que están sobre ellos. Éste es el punto clave para la programación de lacinta. Un material que mueve objetos que están sobre él. Es por eso que en una primera versiónde la cinta en pruebas se tomarán objetos cúbicos que descansaban sobre una superficie fija yestática. A estos objetos cúbicos, uno junto a otro, se les dotaba de una velocidad lineal quese actualizaba en cada paso. Estos objetos son dinámicos, es decir, incluidos en el motor físicoy sobre los cuales actuan fuerzas y velocidades pero que también producen fuerzas sobre otrosobjetos. No obstante en cada paso de ejecución se eliminaba la posibilidad de fuerzas ejercidassobre ellos por otras causas para que el funcionamiento fuera correcto, pues aunque es cierto quelos objetos que transportarán ejercerán fuerzas sobre ellos y por lo tanto un desgaste natural yotras perturbaciones o errores de maquinaria, ésto se puede hacer de forma ajena al motor físicosin necesidad de incluirlo. Lo importante es obtener un comportamiento lógico y realista de loque sería un objeto siendo transportado por la cinta. En la figura 21 se pueden ver capturas delprimer prototipo de cinta que se está comentando. En esta primera versión se observa un modelomuy tosco, sin texturizar ni optimizar pero que cumplía su objetivo. Mover un objeto cúbico deun punto a otro.

Figure 21: Imágenes pruebas de transporte de un objeto físico por la cinta transportadora.

Una vez que se comprobó que el sistema ideado y programado funcionaba, se procedió a incluirlos objetos físicos cúbicos necesarios para tener una cinta transportadora completa. La dinámicade la cinta es lineal. Una vez activada va de 0 a 0.5m/s de forma lineal. Todavía no se han incluidolas opciones de funciones de transferencia personalizadas pues será en el editor de plantas donde seconfigurarán estas opciones. En la figura 22 se puede observar el primer prototipo, parcialmentetexturizado, del primer prototipo de cinta transportadora. Aunque sigue siendo algo tosco, ya sehan incluido los elementos que conforman la cinta, las placas de la cinta, los engranajes que mueven



las placas y los soportes. Esta cinta está formada por aproximadamente unos 50 obejtos cúbicosfísicos sobre un soporte rígido y estático que basicamente forman la cinta transportadora.

a)

b)

Figure 22: Imágenes de la Cinta transportadora parcialmente texturizada. a) Imagen en reposo.b) Imagen transportando objetos.

El modelo final tras varias modificaciones se muestra en la figura 23. Aunque la versión anterior,que estaba formada por 50 objetos cúbicos que se encargaban de mover los objetos encima deun punto a otro, funcionaba correctamente, el consumo computacional y gráfico era algo elevadoincluso estando parcialmente texturizado. Se fueron reduciendo el número de objetos que formabanla cinta y aumentando su tamaño para seguir cubriendo toda la longitud de la cinta. También seeliminaron objetos 3D que realmente eran innecesarios para mejorar el rendimiento gráfico, llegandoa una solución más optimizada que la versión anterior y con un funcionamiento prácticamenteidéntico.

En la figura 23 se puede observar como se ha mejorado el apartado gráfico incluyendo algunoselementos decorativos como el cuadro eléctrico. Como se ha comentado anteriormentee, la cintaconstará de 2 modelos, el físico y el 3D. El modelo físico de la cinta se muestra en la figura 24,mostrado mediante figuras geométricas constituidas por segmentos.



a)

b)

Figure 23: Imágenes del modelado final de la cinta transportadora y la zona de caída de cajas.



a)

b)

Figure 24: Imágenes del renderizado de los objetos físicos que realizan la simulación de la cintatransportadora.



Obviando el modelo 3D pues no tiene efecto físico en la simulación, se va a explicar como se haprogramado el funcionamiento de la cinta. El modelo físico completo de la cinta está compuestopor los siguientes bloques, mostrados en la figura 24:

• 1 bloque cúbico estático

• 1 bloque cúbico dinámico

• 2 bloques cúbicos estáticos laterales

El funcionamiento es el siguiente:

1. Al activarse el actuador correspondiente (ON, variable bool a “true”), se le aplicarámovimiento lineal al bloque dinámico. El bloque dinámico descansa sobre el bloque estático.

2. Al aplicar movimiento, este bloque, que descansa sobre el estático, se deslizará aunque sufrirározamiento debido a que está actuando la fuerza de la gravedad sobre él, por lo que en cadapaso de ejecución habrá que corregir la velocidad para compensar este rozamiento no deseado.El movimiento se aplicará directamente sobre las variables de velocidad del objeto, dentrode la clase, forzando a su movimiento.

3. El objeto dinámico se moverá una distancia determinada. Al recorrer esta distancia, el objetovolverá a su posicion inicial, mediante un forzado de la variable de posición pero manteniendola misma velocidad.

4. Esto provocará que el efecto sea el de una cinta. El objeto moverá cualquier otro objeto quetenga en su superficie una determinada distancia, volverá a la posición inicial, pero si eseobjeto sigue sobre su superficie, aunque en otra zona distinta ahora, seguirá desplazandoloigual.

5. El movimiento que se aplica es de dinámica lineal. Partiendo de 0 m/s y llegando a 0.3m/s.Una velocidad que se ha visto razonable para el escenario que se ha dispuesto y que sepresentará en un apartado posterior de este proyecto.

3.4.2 PLATAFORMA GIRATORIA + CINTA

La plataforma giratoria o “TurnTable”, tiene una implementación muy parecida a la Cintatransportadora. Está basada 2 únicos objetos físicos que se muestran en la figura 25. El objetorectangular es estático y soporta al objeto dinámico que será el que simule realmente la mesagiratoria. Este objeto deberá ser capaz de moverse de 0 a 90º, y linealmente en los dos sentidospara darle a la mesa mayor funcionalidad.

La clase detectará si se ha pulsado el actuador correspondiente y pondrá en marcha la funcióncorrespondiente. Sea cual sea la función escogida, el procedimiento es el mismo. Al objeto dinámicose le asignará una velocidad, en x, z o en ambos en caso de movimiento circular, mediante lasvariables que tendrá en cuenta el motor físico para hacer la simulación de colisiones y aplicar lasecuaciones físicas:



Figura 25: Código en C# que describe el movimiento de la cinta giratoria mediante las variablesde velocidad.

El movimiento lineal, aparte de lo ya comentado, sigue la misma rutina que en el caso de lacinta transportadora. Avanzará una pequeña cantida de espacio y se reposicionará el objeto cuandoalcance ese espacio en su posición original sin cambiar el vector de velocidad para no alterar lafísica del sistema, pues para nosotros es como si no hubiera ocurrido nada.



Figure 26: Imágenes del renderizado de los modelos físicos y 3D de la plataforma giratoria.

El modelo en 3D debe seguir fielmente a la simulación física interna. Lo que nos lleva a quelos rodillos del modelo en 3D que se observa en la Figura 26, deberán actualizar su posición enel espacio y ángulo dependiendo de la velocidad angular y lineal del objeto dinámico para lo cualhabrá que hacer equivalencias de velocidades angulares con lineales, ver Figura 27.

Figura 27: Código en C# que calcula la posicion y ángulos de los modelos 3D de los rodillos enfunción de la velocidad lineal del objeto físico.

En las líneas de código presentadas en la Figura 28, se muestra un claro ejemplo delreposicionamiento y reorientación del elemento dinámico para evitar errores en la simulación de lamesa. Ésto es debido a que en realidad el objeto dinámico no está unido a ningún otro elementocomo lo estarían las partes que componen a un elemento así en la realidad por ejemplo mediante



engranajes. Es en realidad un objeto libre que se está controlando para que simule ciertas acciones.Cuando, por ejemplo, tiene una caja que está transportando, ésta está ejercienzo fuerzas sobrela mesa, lineal/angular, e inevitablemente el motor físico lo tendrá en cuenta y se produciránmovimientos no deseados en los ejes x, z. Estos errores deben ser corregidos al comienzo delmétodo Update. Existe la posibilidad de realizar esto último mediante el método opcional del quese comentó que se disponía, siendo necesario su uso en este caso.

Figura 28: Código en C# del método “Update2” de la plataforma giratoria que se ejecutará trasel paso por el motor físico.

3.4.3 GRÚA

El caso de la grúa es más complejo que los anteriores. El modelo completo en 3D puede verse enlas figuras 29 y 30. En este caso el modelo de la grúa tiene varias partes implicadas.

Figure 29: Imagen del modelo completo de la grúa del proyecto, garra abierta y bajada.



Figure 30: Imagen del modelo completo de la grúa del proyecto, garra abierta y subida.

La primera parte implicada es la estructura principal, los soportes sobre los que descansa lagrúa y por los cuales se mueve, formada por varios cuerpos físicos estáticos. La estructura principalnunca se moverá, será estática durante toda la simulación, no adquirirá velocidad, aceleración ofuerza alguna, ver figuras 31 y 32.

Figure 31: Imagen del modelo físico que simulará el funcionamiento de la grúa.



Figure 32: Imagen del modelo físico que simulará el funcionamiento de la grúa.

En segundo lugar está el brazo de la grúa, formado por dos cuerpos físicos, en principioinamovibles pero que cambiarán al imprimirle movimiento. Estos dos cuerpos forman un únicoobjeto en el simulador. Se puede mover linealmente en dos sentidos y subir/bajar. El brazo debepoder interactuar con el resto de objetos del simulador sin que éstos tengan efectos sobre su posicióny velocidad pero si al contrario. Para ello se dota al brazo de una masa elevada, de esta forma siun objeto choca con el brazo no repercutirá en su estado. El último de los elementos es la garraque está formada por dos cuerpos cúbicos que serán los encargados de interactuar con los objetos,ver figuras 33 y 34.

Figure 33: Imagen de la grúa sosteniendo una caja.



Figure 34: Imagen de la grúa soltándo una caja en movimiento.

Para realizar la simulación de la sujeción de un objeto se ha optado por usar “choque conjunto”.Si una de las dos partes de la garra colisiona con un objeto, el sistema físico se encarga delmovimiento necesario entre garra y objeto. En el momento en que exista una colisión en ambaspartes de la garra, se comprueba que el objeto definitivamente se encuentra en una posición en laque es posible sujetarlo físicamente. Si éste es el caso, se procede a declarar al objeto inamovibley a la grúa se le da la orden de aplicar al objeto sus mismas velocidades en cualquier dirección.Las líneas de código que gobiernan la garra se presentan en la figura 35. De ésta forma el objetoseguirá a la grúa en el recorrido que haga sin moverse de su posición relativa a la grúa. Una vezque se envié la orden de abrir la garra, la grúa devolverá el estado inicial al objeto, quedando asínuevamente expuesto a cualquier tipo de fuerza externa.

Para la detección de colisión se utiliza un método extra de colisiones entre objetos. Como losúnicos objetos dinámicos libres que actualmente existen en el simulador son cajas, lo que se hacees un barrido por cada una de las cajas. Se comprueban las “ID’s” de colisión y si existe unacolisión de los modelos físicos o “BoundingBox” de la caja con los objetos que forman la garra.Si se detecta una colisión se procede al movimiento de la caja para alinearla con la garra segúnel avance de la garra tal y como sucedería en la realidad. En el momento de la colisión doble, sila orientación de la caja es cercana a la orientación de la garra, el objeto se podrá agarrar. Enotro caso, supongamos que la caja estuviera a 45º, las garras al cerrarse expulsarán el objeto porrozamiento.



Figura 35: Código C# que se encarga del funcionamiento de la garra mediante detección decolisiones añadidas.

3.4.4 RAMPA

Las rampas no son más que objetos físicos estáticos que servirán para guiar las cajas hacia lassalidas, en este caso los destructores, que serían paso a otras zonas de la planta. Están formadaspor varios objetos y poseen unos coeficientes de rozamiento adecuados para simular una superficiemetálica pulida que permitirá a las cajas deslizarse facilmente por su superficie. En la figura 36 sepresenta el modelo en 3D y el modelo físico. Las rampas no disponen de actuadores, ni sensores.No tienen control alguno y están completamente gobernadas por el motor físico. En la figura 37 sepuede ver lo más relevante de la clase “Rampa.cs”. Se observa que tan solo es una declaración deobjetos y su posicionamiento en el escenario mediante las variables correspondientes a cada cuerpoo “Body”.



a)

b)

Figure 36: Imágenes de los modelos a) 3D , b) físico de la rampa.



Figura 37: Código en C# de la declaración e inicialización de un elemento Rampa.

3.4.5 DESTRUCTOR

Dado que para el escenario prototipo se han utilizado cajas de madera, es necesario crear unelemento que sea capaz de “destruirlas”. Es decir, si una caja ya no es necesaria en el escenario, sique será necesario liberar o destruir dicha caja para liberar recursos de la ejecución. En las figuras38 y 39 se pueden observar tanto el modelo 3D como el modelo físico que detecta las colisionesmediante su “BoundingBox”.

Figure 38: Imágenes del renderizado 3D de un Destructor.



Figure 39: Imágenes del renderizado del modelo físico de un Destructor.

El código del destructor es muy simple y solo se basa en unas “ID’s” que contienen las cajas.Un objeto cúbico físico simple se encargará de comprobar si se ha producido alguna colisión con elmismo. En ese caso se comprobará la ID del objeto en colisión y se liberarán los recursos de dichoobjeto. El código que gobierna las colisiones es similar al caso de la garra en la grúa y se muestraen la figura 40.

Figura 40: Código en C# para chequear las colisiones del objeto físico del Destructor con otrosobjetos del escenario y eliminarlos encaso positivo.

3.4.6 PISTON

Se ha desarrollado una simulación de un pistón neumático. Dado que el prototipo de escenarioen mente, al ir desarrollandose el proyecto, era una planta clasificadora de cajas, se pensó que



sería conveniente desarrollar un elemento de empuje. El modelado definitivo en 3D se muestra enimagenes en la figura 41.

La estructura programada es simple. Varios objetos físicos estáticos y un único bloquedinámico/estático. Cuando se dice dinámico/estático es debido a que el bloque no es realmentedinámico, sino estático pero al moverse se comporta como dinámico cuando se ejecuta el sistema decolisiones. El pistón permanecerá completamente estático pues sino caería por fuerza de gravedad.En la figura 42 se muestra una porción de código con la definición de los objetos que componen elpistón.

Figura 42: Código en C# donde se declaran las variables de objetos físicos.

Cuando los actuadores que gobiernan la activación del pistón son pulsados, ver figura 43,se modifica la posición del elemento dinámico/estático que se encuentra en el tope del pistónmediante las variable correspondiente. Tras la actualización de posiciones del elemento, se hacepasar por el motor físico y sistema de colisiones. El truco que se ha utilizado para que se comportedinámicamente siendo estático y que no se caiga el objeto físico cúbico por gravedad tiene que vercon el propio sistema de colisiones.

En el apartado 3.1 se explicó que el sistema de colisiones se basaba en profundidad depenetración y un movimiento proporcional a la penetración. El objeto es estático, luego en realidadno importa que se le apliquen velocidades, aceleraciones y/o fuerzas, pues el motor físico lo detectacomo estático y no aplicará fuerzas, velocidades ni aceleraciones sobre él. La velocidad que se leaplica al objeto se hace mediante desplazamiento de su posición.

Si se quiere una velocidad de 0.2m/s se hacen los calculos necesarios según el tiempo de paso deejecución y se calcula aproximadamente la cantidad de espacio que debe recorrer en cada uno delos pasos. Es decir que entre un paso y otro se fuerza la posición del objeto. Si existe otro objetodinámico, como una caja, cercano al pistón y se fuerza la posición del pistón , éste penetrará enla caja. Esta situación será detectada por el sistema de colisiones que se encargará de hacer losmovimientos correspondientes al objeto dinámico, en este caso la caja. De esta forma se consigueel comportamiento deseado.



a)

b)

Figure 41: Imágenes del Pistón. a) Modelo 3D pistón recogido b) Modelo 3D pistón extendido.



Figura 43: Código en C# para la simulación del movimiento del pistón.

Basandose en el pistón se ha desarrollado también un pistón con dos pistones incorporadosreutilizando el código del pistón. En las figuras 44 y 45 se muestran los modelos del piston dedoble actuación.

Figure 44: Imagen del pistón doble en resposo sobre la cinta transportadora.



Figure 45: Imagen del pistón doble empujando una caja.

3.4.7 SENSORES DE BARRERA

Dado que se está hablando de simular una planta industrial, un elemento básico que no debe faltares el sensor de barrera. Aunque son sensores muy simples, son muy utilizados y darán mucho juegoen el simulador para practicar con PLC’s.

La implementación final del sensor de barrera con la que se obtuvieron los mejores resultadosfue mediante el uso de un segmento de colisión. Este segmento, de longitud igual a la separaciónentre los elementos que forman el sensor será el implicado en la detección de los objetos. En cadaiteración de la aplicación se comprueba si este segmento ha intersectado con alguno de los objetosfísicos del escenario. En el caso de obtener una intersección, el sensor se activa cambiando a trueel valor de una variable booleana que se utilizará para otros propósitos en el escenario.

Figure 46: Imagen del Sensor de barrera. Modelo 3D del Sensor con rayo.



a) b)

Figure 47: Imágenes del Sensor de barrera. a) Contacto límite entre objeto y sensor activandose.b) Objeto cercano sin colisionar con el sensor de barrera.

Figura 48: Código C# que muestra como se detecta la colisión con el segmento y la comprobaciónde ID’s.

En la figuras 46 y 47 se muestran capturas de pantalla del modelado 3D y funcionamiento delsensor para objetos con diferentes posiciones. La porción de código relacionada con la detecciónse muestra en la figura 48.

Dado que en el simulador desarrollado en este proyecto los únicos objetos dinámicos que existenson las cajas, al detectarse una colisión se comprobará a que caja corresponde la “ID” del objetoque ha colisionado con el segmento. En las colisiones se modifican los valores de los colores del



rayo y las luces de control para una mejor visualización por parte del usuario como se muestra enla figura 48.

3.4.8 MONTACARGAS

Este elemento no se ha terminado de desarrollar completamente, aunque está practicamentefinalizado. Se ha programado con un objeto físico cúbico que será el responsable de la subiday bajada de elementos. El modelado 3D y físico se muestran en las figuras 49, 50 y 51. Recordandoque no existen uniones mecánicas que mantengan los elementos unidos unos a otros, hay que teneren cuenta que el objeto que debe subir y bajar carga estará inevitablemente bajo la fuerza de lagravedad del motor físico. Si se intentase hacer la simulación mediante la adición de velocidad,aceleración o fuerza en el eje vertical del objeto para que fuera capaz de subir y bajar un elemento,nos encontraríamos con situaciones no deseadas. El elemento encima de la plataforma no tieneporque estar necesariamente en el centro, luego nuestro objeto, que no es más que la plataforma,se inclinaría hacia los lados. No es un método que proporcione buenos resultados.

Figure 49: Imagen del modelado 3D del montacargas detenido.



Figure 50: Imagen del modelado 3D del montacargas subiendo un objeto.

Figura 51: Imagen de la estructura física que conforma el montacargas.



Tras varias pruebas se utilizó la velocidad lineal en el eje vertical para realizar la simulación.La clave para evitar inclinaciones y efectos parásitos en la carga fue resetear el elemento movil encada una de las iteraciones. Al ejecutarse el método Update del montacargas, se anulan las posiblesfuerzas, aceleraciones y velocidades, que se han grabado en sus variables internas, productos delpaso por el motor físico y sistema de colisiones. Asimismo se reorienta el elemento y se le vuelvea asignar la velocidad que debería tener. De esta manera se mantiene el realismo de la acción desubida y bajada de la carga. En la figura 52 se muestra la parte del código relacionada con laactivación del actuador correspondiente y la actualización de la posición de la plataforma.

Figura 52: Código en C# del método Update de la grúa donde se controla el movimiento de lasdistintas partes y se reajustan al comienzo del mismo.

3.4.9 ROBOT 5 GRADOS DE LIBERTAD

Al igual que en el caso del montacargas este elemento no se ha terminado de desarrollarcompletamente, aunque está practicamente finalizado. Lo único que falta por terminar deprogramar es el mecanismo de agarre, aunque ya se ha planteado usar el mismo método queen el caso de la grúa, al fin y al cabo en este caso la garra no deja de ser una pinza al igual queen la grúa. En la figura 53 se muestran capturas del brazo en 3D en diferentes posturas, y en lafigura 54 se puede observar el modelado físico que se implementa en el motor para las colisiones.

El brazo se ha diseñado siguiendo la estructura de una brazo real. Consta de un bloque cúbicofísico por cada una de las partes que lo componen, 4 más la garra. El brazo se podría haber



programado utilizando las matrices de traslación y la de rotación, al igual que se hace de formateórica, donde los ejes están en las articulaciones, en los extremos de los elementos. El problema esque en el motor físico, los ejes de los elementos están en el centro por lo que habría que trasladareste punto hacia los extremos. En vez de realizar la conversión se decide programar la posición decada una de las partes respecto de la anterior y partiendo desde cero.

Figure 54: Imágenes de los modelos físicos del brazo de 5 grados. 4 elementos más la garra.

En las figuras 55 y 56, se muestra el código de la declaración e inclusión en el motor físico decada una de los bloques físicos que componen el brazo. El brazo tendrá una mobilidad de 180º



a)

b) c)

Figure 53: Imágenes del brazo en 3 posiciones diferentes.



en cada una de las articulaciones. El modelado está basado en el Scorbot. El objetivo de aplicaruna masa elevada a cada una de las partes del brazo es porque se va a utilizar el mismo métodoque en el caso del pistón. Debido a que los movimientos de cada una de las partes tendrán variascomponentes, se hace dificil el control de la posición sin que ocurran efectos parásitos debido ala falta de unión mecánica fija, a la fuerza de la gravedad y resto de elementos del escenario. Elmovimiento del brazo está totalmente basado en movimiento articular. Mediante cambios en lasvariables articulares se aplicará la nueva posición de cada una de las partes.

Figura 55: Código en C# de los objetos físicos y otras variables del brazo.

Se parte siempre de la base y se va subiendo, modificando las variables articulares yconsecuentemente su parte correspondiente, hasta llegar a la garra. Se realizan los cálculos, segúnel valor de la variable de la articulación, cual será la nueva posición del elemento en cuestión.El punto que se está calculando es el punto central de la parte del brazo para después poderposicionarla en ese punto. En las figuras 57, 58, 59 y 60 se muestra el código de los cálculos quese realizan para cada elemento. Si el actuador de la articulación correspondiente está activado,la velocidad de movimiento será uniforme y siempre la misma. No se ha implementado ningunadinámica por el momento, al igual que con el resto de elementos. En cada iteración la cantidadde movimiento en la variable articular es constante. Como se conoce el aumento de cantidad,se puede conocer facilmente mediante relaciones trigonométricas cual será la nueva posición delbloque físico.

Una vez calculada la posición, simplemente se sitúa el elemento en dicha posición y se recalculanlas posiciones de los elementos superiores en función de la variable inferior. En caso de estaractivado algún otro actuador superior se realizaría la misma operación, pero eliminando los cálculosinferiores.

Lo que falta por programar en el brazo es el mecanismo de sujeción de la garra.



Figura 56: Código en C# de la inicialización y adición al motor físico de los objetos.

Figura 57: Código en C# del control de la primera sección del brazo. La sección 0 es la base.



Figura 58: Código en C# del control de la segunda sección del brazo.

Figura 59: Código en C# del control de la tercera sección del brazo.



Figura 60: Código en C# del control de la garra sección del brazo.

3.4.10 CONEXION CLIENTE OPC - SERVIDOR OPC - PLC

Para esta aplicación en pruebas, y como se ha comentado anteriormente, se ha optado por unaconexión no física. Es decir, para realizar la simulación de la planta 3D con un programa escritopara el PLC, no será necesario el uso de un PLC real. Se utilizará el simulador de PLC que incluyeel software Unity Pro XL de Schneider Electric. Este simulador se conectará de forma local enel mismo PC con el servidor de OPC de Schneider OFS. La conexión con el OFS se realizará através del menú de pestañas que incluye el simulador 3D. El cliente OPC que se ha integrado en lasolución, está escrito en C#. Para ahorrar tiempo en el desarrollo de la aplicación se ha utilizadoun cliente OPC libre de licencias en C#.

Aunque existen diversos clientes OPC escritos en este lenguaje, se descartaron por noproporcionar el código fuente o ser de pagos y no es el objetivo de este proyecto. En un futurose podría utilizar el conjunto de librerías de la OPC Foundation para el desarrollo de clientesOPC optimizados para el simulador 3D. Durante la conexión del cliente con el servidor OPC, semuestran el listado de variables que están incluidas en los archivos de la programación realizadapara el PLC con Unity Pro. Actualmente todas las variables que se permiten en el simulador 3Dson boolenas, true/false o 0/1 según se prefiera. Lo comentado no implica que el OFS no admitavariables analógicas. Para éste escenario no se han implementado aunque si se implementarán enfuturas modificaciones de la aplicación.

Para la conexión con el servidor OPC de Schneider, OFS (OPC Factory Server), se utilizará uncliente OPC escrito en C# que se ha integrado en la solución. El cliente esta basado DA o “DirectAccess” y se utiliza de forma directa en el mismo PC donde se encuentra tanto el servidor OPC



como el programa del PLC Unity Pro. Se disponen de dos botones en el cuadro de control para laconexión y desconexión con el OPC.

Figura 61: Captura de pantalla del formulario de conexión Cliente - Servidor OPC.

El cliente OPC inicialmente se manejaba desde un formulario para la escritura y lectura devariables. Se ha tenido que modificar parte del código para que la escritura/lectura se realicedesde métodos internos que serán llamados utilizando hilos pseudoparalelos desde el programaprincipal. En Unity Pro las variables se envian al servidor OPC con la descripción de item“Nombre_Proyecto!Nombre_variable”. Sabiendo ésto se puede localizar desde el cliente unavariable en concreto dentro del servidor OPC, para la escritura o lectura de una variable. Eneste proyecto los actuadores se llamaran Axx y los sensores Sxx y Pxx. El significado y numeraciónde éstos aparecen en el manual de usuario.

Existirán hilos de escritura y lectura, así como hilos prioritarios y secundarios, ver figuras 62y 63. La creación de hilos diferentes se basa en que variables se están leyendo o escribiendo. Secomprobó tras varias pruebas que la lectura/escritura individual de actuadores y sensores en elservidor OPC era lenta, en especial en el caso de la escritura en el OPC. La solución escogidaque mejor resultado ofreció fue la lectura en bloque y la escritura individual. La lectura de todoun conjunto de 20 actuadores lleva un tiempo aproximado de 30-40ms. Mientras que la escrituraindividual de 1 único sensor en el OPC puede llevar unos 15ms. El OPC utilizado parece serbastante lento en escritura y lectura. Por ello se necesitan hilos.



Figura 62: Código del método para la lectura de actuadores del servidor.

Figura 63: Código del método de escritura de sensores no prioritarios en el servidor OPC.



El hilo de lectura estará continuamente en ejecución. Este hilo se detiene cuando existe alguncambio en algún sensor. Entonces se toman todos los sensores que han cambiado de estado y seescriben uno a uno.

En el simulador existen sensores prioritarios que corresponden a los sensores de barrera. Dadoque estos sensores son críticos pues dependen del paso de objetos dinámicos que cambian deposición, se deberán escribir inmediatamente en el OPC para que el PLC reciba los datos y actuela programación de la planta en el PLC en consecuencia. En este caso la escritura del resto desensores se detendrá para proceder a escribir los prioritarios, tras lo cual se volverá a escribir pordonde se dejaron los sensores no prioritarios Sxx.

3.4.11 CUADRO DE CONTROL Y OPCIONES

Para el control de la aplicación, tanto en modo manual como automático, se ha diseñado unainterfaz amigable formada por un cuadro de control dividida en pestañas. En cada una de laspestañas se encuentran diferentes controles, actuadores, sensores y conexión de OPC, ver figura64. En el cuadro de operación a la derecha se encuentran los controles de activación de modomanual/automático y otros que se pueden utilizar junto con variables que se declaren en el PLC.

La programación es sencilla. Todo el cuadro está basado en texturas 2D que se renderizarán encada paso de ejecución. Las texturas corresponden al cuadro en sí y a los botones. Cada uno delos botones se posiciona en base a los ejes que forman el formulario general donde está embebido elsimulador. En función de las características de ancho/alto de la ventana de la aplicación la situaciónde los botones se mantiene siempre en el mismo sitio, es decir, no importa que se aumente el tamañode la ventana, el cuadro permanecerá con el mismo tamaño y en la misma posición, ver figura 66.

Para la detección de pulsado de botones se detecta la posición en la ventana donde se harealizado el click de ratón. Cotejando la posición del click con las posiciones de los botones sedetectará una coincidencia o no, y si es así se cambiará el estado del botón y su imagen. Conrespecto a los sensores solo hay que detectar de forma interna cambios en las variables booleanasde los sensores. El código para una parte de los actuadores se presenta en la figura 67.

Figura 65: Código de la declaración de variables que contendrán las imágenes para los elementosdel cuadro de control.



a)

b) c)

Figure 64: Imágenes del cuadro de actuadores de la aplicación. a) Cuadro de actuadores, b) Cuadrode sensores y c) Cuadro de conexión OPC.



Figura 66: Código para posicionar los elementos en el mismo lugar sin importar el tamaño de laventana.

Figura 67: Código para la detección de pulsado de botones en la aplicación. En este caso secomprueban los 15 primeros actuadores.


3 diseÑo e implementacion del simuladorbibing.us.es/proyectos/abreproy/12094/fichero/3... · 3...

Documents