Laboratorio a distancia - módulo de control Helicóptero CE 150

Texto completo

(1)Proyecto de Grado. Laboratorio a distancia: Módulo de control Helicóptero CE 150. Julian Sanclemente Mansilla Asesor: Mauricio Guerrero. UNIVERSIDAD DE LO S ANDES DEPARTAMEN TO DE ING ENIERÍA ELÉC TRIC A Y ELEC TRÓ NIC A PRO YEC TO DE G RADO 2005.

(2) Resumen En este proyecto de gr ado se implem entó una práctica de control, basada en el m odelo del Helicóptero CE 150, para el laboratorio a distancia de la Univer sidad de Los An des (ULA) par a apoyar la formación en el área de control. Esta práctica consiste en aplicar un sistema de control PID al h elicóptero a través de la h erramienta MATLAB, par a que pueda ser utilizado desde cualquier com putador conectado a Internet. La aplicación es educacional y podrá ser utilizada por cualquier per sona interesada en esta área. Al tener esta ap licación en la r ed, se podr á pensar en la op ción de soportar curso s a distancia, brin dar este servicio a otras instituciones y así mismo com partir con ellas este tipo de laboratorios. La finalidad del proyecto es br indar una alternativa para aproximarse a la realidad del control a través de exper iencias reales..

(3) Tabla de Contenido 1.. Introducción ...............................................................................................................1 1.1 Objetivo s ...........................................................................................................1 1.1.1 Objetivos Generales ..................................................................................1 1.1.2 Objetivos Específicos ................................................................................2 2. Marco Teórico ...........................................................................................................2 2.1 Antecedentes Locales........................................................................................2 2.1.1 Aplicación de la tele in strumentación para el desarrollo de laboratorios a distancia y m anejo de instrumentos [1]. ....................................................................2 2.1.2 Aplicación de la tele in strumentación para el desarrollo de laboratorios a distancia y m anejo de instrumentos: módulo s de configuración de parámetros e interfaz para el usuario [2].........................................................................................4 2.2 Antecedentes Externos ......................................................................................5 2.2.1 MIT W eblab ( iLab)[4] ...............................................................................5 2.2.2 A DIstant Reality Envirom ent for Control Teach ing (DI RECT) [7] ........7 3. Desarrollo ..................................................................................................................8 3.1 Estudio del mo delo [8] ......................................................................................8 3.1.1 Especificaciones del h elicóptero ...............................................................9 3.1.2 Especificaciones de la unidad de interfase y la tarjeta I/O MF614 ......... 10 3.1.3 Dim ensiones y pesos ............................................................................... 10 3.2 Alternativas de control .................................................................................... 11 3.2.1 GPI B........................................................................................................ 11 3.2.2 Soft ware prop io ....................................................................................... 11 3.2.3 MATLAB [9] .......................................................................................... 11 3.3 Arquitectur a propuesta .................................................................................... 13 3.3.1 Módulo interfaz/hombr e: Estructura general .......................................... 16 3.3.1.1 Documento de ingreso de datos........................................................... 16 3.3.1.1.1 Validación ..................................................................................... 17 3.3.1.2 Documento de salida de datos ............................................................. 18 3.3.2 Módulo Controlador Práctica CE 150: Estructur a gener al Archivo .m .. 18 3.3.3 Módulo Web Cam ................................................................................... 21 3.3.4 Com un icación entre m ódulos .................................................................. 21 3.3.4.1 Interfaz Hom br e/Máquina con Mó dulo Controlador CE 150 ............. 21 3.3.4.2 Controlador CE 150 con Un idad de Interfase ..................................... 21 3.3.4.3 Módulo Interfaz Hombr e/Máquina con la Módulo Web Cam ............ 21 3.4 Práctica prop uesta: Control PID Elevación ..................................................... 21 3.4.1 Sim ulación de Estímulos ......................................................................... 22 3.4.1.1 Documento de ingreso de datos........................................................... 22 3.4.1.2 Controlador Estím ulo s: Arch ivo .m “sim ulación” .................................. 27 3.4.1.3 Documento de salida de datos ............................................................. 29 3.4.2 Car acterización de la p lanta .................................................................... 30 3.4.2.1 Documento de ingreso de datos........................................................... 31 3.4.2.2 Archivo .m: Controlador ..................................................................... 33 3.4.2.2.1 Defin ición de contadores [10] ....................................................... 33 3.4.2.2.2 Com unicación con los contador es ................................................. 33. i.

(4) 4 5 6 7. 3.4.2.2.3 Módulo de tiem po real .................................................................. 34 3.4.2.2.4 Documento de salida de datos ....................................................... 35 3.4.3 Control PID ............................................................................................. 36 3.4.3.1 Documento de ingreso de datos........................................................... 36 3.4.3.2 Archivo .m: Controlador ..................................................................... 38 3.4.3.3 Documento de salida de datos ............................................................. 39 3.5 Herramienta de análisis de resultados ............................................................. 40 3.5.1 Opcion es de capt ura de v ideo .................................................................. 43 3.5.1.1 Windows Media 9 Series [11] ............................................................. 43 3.5.1.2 Cam studio [12] .................................................................................... 43 3.5.1.3 Webcam Watchdog [13] ...................................................................... 43 Conclusiones ........................................................................................................... 44 Perspectivas ............................................................................................................. 45 BI BLI OGRAFI A..................................................................................................... 47 ANEXOS................................................................................................................. 48 7.1 Información técnica del cableado de la tarjeta MF614 ................................... 48 7.2 Código Jav ascript de Validación ..................................................................... 50 7.3 Código p ara def inir vector de Trayectoria ...................................................... 52 7.4 Código p ara gen erar gráfico de sim ulación de Estímulos ............................... 53 7.5 Código HTML de la página de salida de Estím ulo s........................................ 53 7.6 Código de arch ivo .m de caracterización ........................................................ 53 7.7 Código de f unción que convierte controlador continuo a polinom io discreto 58 7.8 Código de arch ivo .m de control PID.............................................................. 58. ii.

(5) 1. Introducción En la educación de hoy día, las prácticas exp erimentales son un factor im portante para el desarro llo académico de cualquier estudiante, ya que a través de ellas se crea la conexión entre lo s conceptos teóricos y la r ealidad. Actualm ente en la ULA se desarro llo una prop uesta de un Labor atorio a Distancia y se dio in icio a dich a actividad con el desarrollo de un sistema gen eral de interconex iones configurable rem otamente que un e in strumentos de m edición con algunas prácticas. El objetivo princip al de este laboratorio es poder ofrecer al estudiante la posibilidad de aproxim arse a experiencias reales las cuales contribuyen al desarrollo integral e intelectual de la per sona mediante la utilización de tecno logías modernas de información, así como la f lexibilidad ofrecida por Internet. Este labor atorio a distancia que se esta desarrollando permitirá mejorar aspectos como: •. La ocupación de p uestos de trabajo en un laboratorio.. •. El tiempo representado en tener que asistir físicam ente al laboratorio para cualquier estudiante.. •. El alto costo que implica ofr ecer un espacio de trabajo y un asistente permanente.. •. Mayor utilización de equipos costoso s con los cuales no es viable hacer laboratorios p erm anentes masivos.. La solución de estos problem as a través de la im plementación de la nuev a práctica y el laboratorio a distancia, ofrecen ben eficios como aum entar el núm ero de prácticas disponibles, el uso eficiente de recurso s, la activa particip ación de m ás est udiantes, y por sup uesto facilita la cr eación de una p lataform a complem entaria de cono cim iento. En este proyecto se va a realizar un estudio detallado de la propuesta y av ance del laboratorio a distancia que se esta desarrollando actualmente en la ULA y se vinculara una pr áctica en el área de control utilizan do el m odelo del Helicóptero CE 150.. 1.1. Objetivos. 1.1.1 Objeti vos Generales • •. Integrar el módulo de control: Helicóptero CE 150 al laboratorio a distancia de la Un iver sidad de Lo s An des. Am pliar el ran go de prácticas disponibles en la Univer sidad de los An des en el ár ea de control..

(6) 1.1.2 Objeti vos Es pecíficos •. Diseñar e implem entar un a interfase de usuario final a través de la cual persona conectada a la red po drá tener acceso a la práctica del Helicóptero CE 150.. •. Diseñar e implementar el soft ware en car gado de m anejar la práctica del helicóptero. Este estará encar gado de interpretar las señ ales que envía el usuario por medio de la interfase final y comunicár selas al Helicóptero CE 150 como señales de control.. •. Poder mostrar el desarro llo del exper im ento en tiempo real. El usuario podrá ver a través de una Web Cam, como el helicóptero responde a las señales de conf iguración que se le han enviado.. 2.. Marco Teórico. 2.1. Antecedentes Locales. 2.1.1. Aplicación de la tele instrumentación para el desarrollo de laboratorios a distancia y manejo de instrumentos [1].. Este proyecto tenía como o bjetivo principal diseñar la ar quitectura base del laboratorio a distancia de la ULA. En el diseño de esta arquitect ura se planteó una p lataform a que permitirá que el usuario pueda realizar m edicion es y conf iguraciones de dif erentes dispositivos por m edio de Internet utilizando el protocolo GPI B como base. To dos los instrum entos que se utilizaran en este laboratorio deben usar el protocolo GPI B al igual que las prácticas que vayan a ser conectadas. En la Figura 1 se puede o bservar el resultado final de la ar quitectura base diseñ ada en este proyecto. En esta podem os o bservar que el diseño general del laboratorio se puede div idir en 3 blo ques. El prim er bloque lo componen los clientes, lo s cuales a través de una conex ión remota (Internet o Intranet), podr án conectarse al laboratorio a distancia a través de la interfase Hom bre/Máquina. En el segun do blo que se encuentra el servidor, el cual es el encar gado de controlar el laboratorio a distancia. En este blo que se llev aran a cabo procesos com o: m anejo de clientes, validación de usuario s, manejo de colas y turnos, accesos a las bases de datos, y los controles de configuración. Este servidor recibirá la inform ación entrante de los clientes por las conex iones TCP/IP, pro cesara la información y la com unicara a los respectivos instrum entos o prácticas conectadas por medio del el bus GPI B El tercer bloque del labor atorio lo componen los instrum entos y las prácticas conectadas al bus GPI B por m edio del sistem a de interconexion es. Este sistem a de interconexion es es el en car gado de recibir la inform ación enviada por el serv idor por el bus GPIB y. 2.

(7) hacer las conexion es respectivas entre la práctica deseada y los instrumentos que deben tom ar los datos. El protocolo permite que el controlador sea capaz de realizar hasta 15 conexiones con distintos dispositivos de m edición con una tasa de transferen cia de 1Mbyte por segun do (valor nominal). La lon git ud de lo s cables puede ser de 20 metros entre el controlador y el principio del bus (8 bits) y de 2 m etros entre los instr um entos. Es importante mencionar que en este sistema las prácticas también son consideradas com o instr um entos. En caso tal que todo s lo s instr umentos se encuentren con ectados al sistema de interconex ión, el laboratorio a distancia po dría manejar un total de 8 prácticas.. LABORATORIO A DISTANCIA DE LA UNIVERSIDAD DE LOS ANDES Instrumentos Osciloscopio Mult im et ro V ol tim et ro Fuent e DC Gen . S eñales Cli ent e 1. Servidor. Cont rol del Servidor. Manejo GP I B. Sistema de Interconex ion. Cliente 3. Modem. Cli ente 4. Base de Dat os. M anejo Client es. Et hernet. I nt ernet Cl ient e 5. Servidor. Bus GPIB Cliente. Tarjet a GP IB. Cli ent e 2. Conexion Remot a Cliente 6. P rac. 3. Pract ica 1 Prac. 2. I nt erf az Hom breMaquina. P rac. 5 P rac. 4. Prac. 6. Practicas. Figura 1. Diagram a general del laboratorio a distancia de la ULA Los in strum entos que se tienen act ualm ente en el laboratorio a distancia y los cuales pueden ser configur ados mediante los controladores del fabricante y el sistema de interconexión son: •. Oscilo scop io TDS Ser ie 1000.. •. Multím etro FLUKE 8500 A.. •. Voltím etro HP 3437 A. 3.

(8) •. Fuente de voltaje y de corr iente. •. Gener ador de f unciones HP 3325 A.. •. Analizador HP 8590. •. Analizador de redes HP 8753. Alguno s de los in strumentos mencionados anteriormente no tenían los controlador es diseñados por los f abricantes, por esto algunos controladores fueron diseñados e implem entados. Estos controlador es pro gram ado s en Visual Basic permiten la com unicación de los instr umentos con el sistem a gener al. El sistema de interconexión diseñado en este proyecto de grado fue pro bado y f unciono correctam ente. Se implem entó un diseño básico de servidor el cual configuraba el sistem a de interconexiones par a tomar unas medidas de una pr áctica sen cilla.. 2.1.2. Aplicación de la tele instrumentación para el desarrollo de laboratorios a distancia y manejo de instrumentos: m ódulos de configuración de parámetros e interfaz para el usuario [2]. Este proyecto de grado se hizo como complem ento al antecedente mencionado en [1]. El objetivo princip al de este proyecto fue desarrollar un m ódulo de prácticas que podían ser configuradas m ediante el protocolo GPI B y a la vez desarrollar un a interfase vía Internet para el usuar io del laboratorio. Inicialm ente se pensó en el diseño de 3 prácticas para incluir al laboratorio a distancia: leyes básicas eléctricas, caracterización de una antena de par che para 2.4 GHz, y un módulo PID. El diseño de las prácticas f ue com pletado, pero so lo se im plementó físicam ente la tarjeta controladora de una de estas, leyes básicas eléctricas. En la figura 2 se muestra el diagrama de bloques de la práctica de leyes básicas eléctricas.. Figura 2. Diagrama de bloques de la práctica Ley es Básicas Eléctricas. 4.

(9) El diagr am a de blo ques de la práctica con sta de 3 blo ques pr incipales. La interfaz GPI B la cual esta conectada con el bus GPI B, encar gada de recibir lo s coman dos que se son enviado s desde el servidor y traducir los en comandos de 2 bytes que ser án transm itido s al segun do blo que. El blo que que esta en la parte inferior a la interfaz GPI B es el bloque de interfaz con JTAG, el cual esta en car gado de hacer la resp ectiva pro gram ación del blo que de la interfaz GPI B (CPLD de Xilinx XC9572). El segundo blo que de esta práctica con sta de lo s m ódulos de Unidad de control de la práctica y el m ódulo Program ador de la unidad de control. El primero (microcontrolador de Microch ip 16F877) es el encargado de recibir los com andos de la interfaz GPI B e interpretarlos y a sea par a configurar la práctica de cierta forma o par a cambiar los parámetros de los elemento que la com ponen. El segundo m ódulo es el que perm ite program ar el m ódulo de control. El tercer blo que es la práctica de Ley es básicas eléctricas. En este m ódulo hay un p uente de r esistencias com puesto por 6 resistencias digitales, 6 interruptores y una fuente. En la figur a 3 se observa la distribución del puente.. Figura 3. Puente de resistencias Cada práctica tiene su propio controlador y una interfase para el usuar io final por medio de la cual podr á configur ar las pr ácticas y ajustar los parám etros de los elementos que la com ponen.. 2.2 2.2.1. Antecedentes Externos MIT Weblab (iLab)[4]. En la un iversidad de MIT se ha venido desarro llan do un laboratorio virtual desde junio del 2000 hasta hoy día. Los prim ero s 3 años del proyecto se intentó proveer acceso en línea a un laboratorio rem oto, el cual debido a co sto, espacio y otras r azones no se había montado. Otro objetivo en esta prim era fase era la de entregar lo s ben eficios. 5.

(10) educacionales de las prácticas experimentales a los est udiantes en cualquier lugar y a cualquier hora. En la segunda f ase, es decir en el últim o año, f ue de desarrollar un software lo suficientem ente estable y avanzado com o para crear una infr aestruct ura sólida de los laboratorios virtuales. Actualmente basados en las experiencias ex itosas que han tenido con lo s experimentos realizados, este software está en una fase bastante avanzada. El soft ware se llama Service Broker ver sión 5.1. Para implem entar este n uevo soft ware se tom o como arquitectur a base la que se m uestra en la Figura 4. •. Figura 4. Ar quitectura iLabs [4] El diseño de iLabs divide las prácticas remotas en tres módulos que son conectados por la ar quitect ura del Web Lab. •. El servidor del W eblab es oper ado por la gente en MIT y se en car ga del m anejo de to dos lo s elem entos Har dwar e que se encuentren conectados a la arquitectura.. •. La aplicación de usuario corre en el computador del cliente y es la encargada de proveer la interfase de op eración con el labor atorio.. •. El iLab Service Broker es el encar gado de recibir la información de la aplicación del usuario y los Lab Servers. A la vez esta en car gado de prov eer el servicio de almacenamiento de datos, servicios administrativos los cuales son genéricos y que pueden ser compartidos por v ario s labor atorios al tiem po dentro de la m ism a universidad.. 6.

(11) Este W eblab de MIT funciona actualmente y presenta m ás de 7 prácticas exper imentales en línea entre las que se encuentran:. 2.2.2. •. Microelectronics WebLab. •. Chem ical reactor. •. Mechanical struct ures. •. Heat exch an ger. •. Instrumentalized flagpo le. •. Shaker table. •. Polym er recrystallization. •. Photo voltaic weather station A DIstant Reality Envirom ent for Control Teaching (DIREC T) [7]. El objetivo principal de DIRECT es crear un am biente que permita que lo s estudiantes aprendan técnicas de diseño de control básicas y que puedan probarlas por medio de sim ulaciones y pr uebas reales en una planta física distante. El estudiante p uede hacer sus diseño s de los controles en h erramientas com o MATLAB o Simulink y posteriormente llevar a cabo la respectiva adaptación de un controlador para manejar algún exper imento real pero que se encuentra en un lugar rem oto. Hasta el momento DIRECT tiene 2 exper imentos los cuales son un pén dulo invertido y un motor DC. La arquitect ura básica de este laboratorio se p uede o bservar en la Figura 5.. Figura 5. Arquitectura general DI RECT [7]. 7.

(12) En esta ar quitectura se plantea como solución tener 4 m ódulos encar gados de manejar el laboratorio, 3 de ello s funcionan como servidores. El primer m ódulo es el St udent Station, el cual es el computador remoto por medio del cual el estudiante se va a conectar con el laboratorio. El módulo de Tutorial Server es el encar gado de guiar al estudiante durante la práctica. Cualquier duda que el estudiante tenga con algún parámetro de ingr eso o con algún concepto teórico podrá ser solucionada a través de este servicio. El módulo Reservation Server es el encargado de controlar todos los experim entos que se ofr ecen en el laboratorio. También es el encargado de dar lo s acceso s de los estudiantes al servidor que controla lo s experimentos. Otra tarea que realiza este m ódulo es controlar que lo s exper imentos este funcionan do de m aner a apropiada. El cuarto m ódulo es el servidor Exp erim ent. Este servidor esta encar gado de recibir la información que v iene del usuario, procesar la y env iarla a los experimentos f ísico s. A la vez esta encar gado de recolectar la inform ación o btenida durante la práctica y enviársela al estudiante.. 3.. Desarrollo. 3.1. Estudi o del model o [8]. El helicóptero CE 150 es un producto diseñado para el estudio teórico y práctico de los principios de la ingeniería de control. Este sistema incluye m odelación dinámica, identificación, an álisis y vario s sistem as de control diseñ ados tanto por m étodos clásico s como moderno s. El modelo CE 150 con sta de 2 m otores DC que son los en car gado s del m ovimiento de las h élices. El cuerpo del helicóptero puede mover se en 2 grados de libertad; la hélice principal es la que controla el movim iento vertical y la hélice secun dar ia el m ovimiento horizontal. Existe un tercer servo-motor el cual es el encargado de controlar el centro de gravedad del helicóptero, desplazan do un peso que se encuentra en el eje del helicóptero. Al mover el centro de gravedad de n uestro m odelo podemos cam biar las características de la planta lo cual permite la po sibilidad de generar variacion es para las prácticas con el mismo instrumento.. 8.

(13) Figura 6. Foto del Helicóptero CE 150 El modelo del helicóptero es un sistema dinámico m ultivar iable con 3 entradas (ángulo de elevación, ángulo de azim ut, centro de gravedad) que pueden ser modificadas y 2 salidas que son la lectura de lo s ángulos en los que se encuentra el sistema. A la v ez, el modelo permite la posibilidad de observ ar las var iaciones de los niveles DC de lo s 2 motores. En la Figura 7 se p uede observar el modelo del sistem a con sus entradas y salidas.. Figura 7. Modelo del sistem a m ulti-var iable [8] 3.1.1. Especificaciones del helicóptero. El modelo del Helicóptero CE 150 incluy e: •. El helicóptero sobr e un soporte.. 9.

(14) • •. Unidad de interfase. Tarjeta multifuncional I/O MF614 (tarjeta P CI). El cuerpo del helicóptero esta tiene las siguientes características: Rotación del cuerpo Hélice pr incipal Hélice secun daria Motor Principal. Motor secun dario. Movimiento del centro de grav edad Medición de Án gulo s. 50° en elevación 160° en azim ut 200/100 en directo 100/60 en directo DC con im anes perm anentes Voltaje m áximo: 12 V , 0-6 A Velocidad máxim o: 9000 RPM DC con im anes perm anentes Voltaje m áximo: 6V , 0-4 A Velocidad máxim o: 12000 RPM Servo motor autónom o PWM Contadores incr ementales. Ta bla 1. Car acterísticas del Helicóptero CE 150 3.1.2. Especificaciones de la unidad de interfase y la tarjeta I/O MF614. La unidad de interfase tiene las siguientes car acterísticas: Adquisición de Án gulo s Amplificadores de potencia. Lógica de contadores incr em entales Servo-amplif icadores PWM DC, 0-240W,12V. Ta bla 2. Car acterísticas de la unidad de interfase La tarjeta multifun cional I/O MF614 tiene 8 canales conver sores A/D, 4 conv ersor es D/A de 12 bits, 4 entradas para enco ders, 4 contador es/tim ers, 8 entradas digitales TTL y 8 salidas digitales TTL. Dos de los tim ers son utilizados para el control PWM de las hélices del helicóptero. Un timer es utilizado par a controlar el centro de grav edad. Las entradas de lo s enco ders y las entradas digitales son utilizadas par a las señales de control del sistema. 3.1.3. Dimensiones y pesos. Cuerpo del Helicóptero: Longitud Soporte del m odelo Altura Máxim a Peso. 300 m m (sin hélices) 360 m m (con hélices) Base cuadrada de 300 x 300 mm 510 m m 3.5 Kg.. Ta bla 3. Dimensión y peso del h elicóptero 10.

(15) Unidad de interfase: Dim ensión 450 x 320 x 155 mm Peso 6 Kg. Tabla 4. Dimensión y peso de la unidad de interfase. 3.2. Alternati vas de control. 3.2.1. GPIB. La prim era opción que se estudio par a m anejar el Helicóptero CE 150 fue a través del protocolo GPI B ya que era el utilizado hasta ahora en el laboratorio a distancia. Para poder controlar el helicóptero con coman do s GPI B era n ecesar io diseñ ar un dispositivo hardwar e que se conectara al bus GPI B, y se com un icar a con la unidad de interfase de la práctica. Una de las razon es por la cual se descartó esta opción es porque el diseño e implem entación de este hardware cam biaría totalmente los o bjetivo s de este proyecto de grado y no se lograr ía completar la práctica de control PID debido a la restricción de tiem po. Otra razón que ayudo a descartar esta opción es que el Helicóptero CE 150 viene con una tarjeta I/O (MF614) que se p uede in stalar en el puerto PCI de cualquier com putador la cual se comunica directamente con la unidad de interfase y perm ite controlar el Helicóptero CE 150. 3.2.2. Software pro pio. El modelo CE 150 viene con un soft war e propio en el cual están dos controlador es PID encargado s de manejar lo s motores de elevación y azim ut. El usuario p uede in gresar los parámetros de los controladores e iniciar el exp erimento y observar los resultados en tiem po real de las m edicion es de lo s ángulos de resp uesta. Las entradas al sistema pueden ser configur adas y modif icadas en el tran scur so del experim ento. Esta alternativa de control sin duda era bastante interesante y cum plía con las necesidades básicas de la práctica de control deseadas. Aun que esta herramienta ofrece una interfase amigable p ara controlar el dispo sitivo, el propósito de este software principalm ente es de dem ostración del modelo y no es po sible alterar el có digo de la misma para po der utilizarla desde un lugar r em oto. Por esta razón esta herr amienta no cum plía con lo s requerimientos m ínim os del proyecto y f ue descartada.. 3.2.3 MATLAB [9] Este modelo educacion al p erm ite ser controlado a través de la h erramienta MATLAB y su Real tim e toolbox (RTT). Debido a las ap licacion es de este toolbox, MATLAB puede conectar se con el m un do real, tenien do así la cap acidad de adquirir inform ación en tiem po real, procesán dola con comando s básico s de la herramienta, y finalmente 11.

(16) devo lviéndo los al mun do exterior. El RTT es quien nos perm ite utilizar el controlador de la tarjeta I/O (M F614) del helicóptero par a po der conectarnos así desde el com putador y la h erramienta, con la unidad de interfase encar gada de env iar las señales de control a la pr áctica. MATLAB a su vez, tiene una h erram ienta que permite crear una aplicación en MATLAB que utiliza las características y capacidades de la World Wide Web para enviar información a MATLAB para que se realicen los respectivos cálculo s y poder mostrar los resultado s en un Web browser. El MATLAB Web Server se com unica a través de TCP/IP entre el cliente y la aplicación. [9]. Para poder establecer la com unicación entre el cliente y nuestra práctica es indispensable el uso de la herram ienta MATLAB; sin em bargo, no es un requisito que el cliente tenga in stalado este soft ware en su m áquina, lo cual nos permite explotar las herram ientas del soft ware sin necesidad que lo s usuario s adquieran la licencia de éste. En la figur a 8 se p uede observ ar com o ser ia la configur ación p ara corr er las ap licacion es en MATLAB desde cualquier com putador que se encuentre en la r ed.. Figura 8. Configuración de aplicaciones Podemos o bservar en la configuración de la figura 8 que el usuario final, a través de un Web Browser que corre en su estación de trabajo p uede enviar la información necesaria a una m áquina en don de correrán lo s procesos de MATLAB, el MATLAB W eb Server y el servidor ( HTTPD). Esta máquina estará conectada al mo delo del Helicóptero CE 150 y será la en car gada de enviar las señales de control a la unidad de interfase mediante la tarjeta MF614. Todo s lo s resultados y mediciones que se tom en durante el experim ento serán dev ueltos al usuario f inal y el lo s podrá o bservar a través del W eb Bro wser. Para poder correr un a aplicación en el MATLAB Web Server, se debe tener una com binación de archivos .m, len guaje HTML y gráf icas. El desarrollo de una aplicación con esta herram ienta requiere de los siguientes paso s de diseño :. 12.

(17) •. Diseñar un docum ento HTML que sea el en car gado de recolectar toda la información necesaria para correr lo s proceso s de cálculos en MATLAB.. •. Diseñar un documento HTML que reciba los resultados procesado s por MATLAB y los m uestre al usuario f inal. (Para el diseño de estos documentos se puede usar cualquier h erramienta de diseño de págin as HTML).. •. Crear un archivo de configuración en don de se incluya el nom bre y to da la información básica de la aplicación que se va a correr en MATLAB ( archivo matweb.conf).. •. Escr ibir un ar chivo .m en MATLAB que tenga las siguientes características: Reciba los datos que f ueron in gresado s en el documento HTML Analice lo s datos de in greso, corra cualquier proceso necesario y genere las gráficas resp ectivas en caso de ser necesario. Colo que toda la información que v a a ser dev uelta al usuario en una estructura de salida de MATLAB. Llame a la f unción htmlrep, la cual es en car gada de llamar al documento HTML don de el usuar io final po drá v isualizar lo s resultado s. La cantidad máxim a de inform ación que se le puede env iar a este do cumento HTML es de 256Kb. Debido a las f acilidades y ventajas que nos ofr ece la opción de MATLAB y sabien do que la Univer sidad de los An des tiene licen cias de este soft war e, se tom o la decisión de que MATLAB sería la herram ienta que se va a utilizar p ara controlar n uestro m odelo el Helicóptero CE 150.. 3.3. Arquitectura propuesta. El prim er paso en la etapa de diseño para vincular el m ódulo de control al labor atorio a distancia de la ULA f ue estudiar a fondo la arquitectura básica que esta planteada en la figur a 1. Se determinó que era necesario utilizar el mismo servidor que ya existía y el cual estaba controlan do el bus GPI B que m aneja to das las prácticas. Debido a que el modelo del Helicóptero CE 150 utiliza un dispositivo har dware dif erente a la tarjeta GPI B utilizada por las otras prácticas del laboratorio a distancia, y el servidor tiene el puerto PCI disponible p ara adicionar este h ardware no hay mayor pro blema de com patibilidad en la integración de la práctica de control al sistema hardwar e del servidor. A nivel de soft war e, según la ar quitect ura prop uesta en [1] y [2], cada instr um ento y cada práctica que se v incule al laboratorio a distancia de la ULA debe tener su propio controlador. En la figura 1 vemos en el módulo del servidor que existe un control que maneja todo s estos controladores indepen dientes y se comunica con la tarjeta GPI B que. 13.

(18) enviará lo s respectivos comando s a través del bus a las prácticas o instrum entos. Por esto se pensó que la pr áctica del Helicóptero CE 150 debía tener su propio controlador. Com o el software que se va a utilizar para controlar el helicóptero CE 150 (MATLAB) es diferente al soft ware utilizado por las pr ácticas e instrum entos controlados por GPI B y estos pueden correr simultáneam ente, a nivel de soft ware tampoco hay ningún problem a en la vinculación del m ódulo de control. Teniendo en cuenta que no habr á nin gún problema a nivel soft ware ni har dware con la vinculación del m ódulo del Helicóptero CE 150, y tenien do en cuenta todas las características necesarias para po der correr una aplicación en el MATLAB W eb Server se llegó al diseño de un a ar quitect ura básica que se m uestra en la f igura 9. De la figura 9 podemos observar que la integración del módulo del helicóptero CE 150 se va a hacer en el mismo servidor del laboratorio a distancia. En el mó dulo del servidor podemos o bservar que se va a diseñar un controlador de la práctica CE 150 el cual será manejado por el control del servidor. Este control será el en car gado de m anejar todo lo correspondiente a la asign ación de turnos, a guardar la inform ación reco lectada por las prácticas en una base de datos y a autorizar a lo s estudiantes a r ealizar los r esp ectivos experim entos. No obstante, podemos observar que el controlador de la práctica CE 150 va a ser completam ente independiente del resto de controladores.. 14.

(19) Figura 9. Ar quitectura de vinculación prop uesta. 15.

(20) Este controlador de la práctica CE 150 debe tener las car acterísticas mencionadas en el punto 3.2.3. Este controlador será el en car gado de recibir toda la información que ingrese el usuario a través de la página HTML en la interfaz hombre/m áquina (módulo cliente en la figura 9) la procesara y env iara las respectivas señales de control a la unidad de interfase que controlará el helicóptero. Una vez term ine el experim ento, el controlador estará encar gado de recibir los resultados tom ado s por la unidad de interfase y los procesara para enviarlo s posteriormente al usuar io en un gráf ico. En el momento que se diseño la ar quitectura de la práctica del helicóptero CE 150 se concluyo que es de vital im portancia que el usuario p ueda observar que esta sucediendo m ientras transcurre la práctica que se este implementando. Por esto se agrego a la arquitectura una Web Cam que se con ecta al servidor por m edio del p uerto USB y la cual se conectara con la interfaz hom bre/máquin a para tran sm itir en tiem po real los m ovimientos y respuestas del helicóptero a los coman dos programado s en el experimento. Esto le dará al usuario la sensación de estar presente en el laboratorio donde están transcurrien do los h echos. 3.3.1 Módulo interfaz/hombre: Estructura general. 3.3.1.1. Documento de ingreso de datos. El primer paso en el diseño de este documento HTML es tener claro cuales son los datos necesarios que se le deben pedir al usuario de tal forma que el experim ento que se vaya a realizar sobre el m odelo del helicóptero CE 150 corra bien. Para esto el encar gado de diseñ ar la págin a puede utilizar cualquier herram ienta de pro gramación por ejem plo Front Page de Microsoft, PageMill de Adobe o HoTMetaL de SoftQuad o cualquier otra con la que el encargado de diseñ ar la página se sienta m ás cóm odo. Dentro del có digo básico del documento de in gr eso de datos hay ciertas líneas básicas que deben estar incluidas dentro del cuerpo de la págin a HTML par a que se p ueda correr la ap licación en MATLAB. Este es el formato general que debe tener dicho docum ento: <html> <head > <!--En este punto va la in form ación básica de la página- - > </h ead > <Va lidación de datos> <body> <fo rm action="/cgi-bin/m atweb.exe" method="POS T"> <input typ e="hidd en" nam e="mlmfile" valu e="a rchivo .m"> <p >Variable: <input type="text" name="nombre_de_la_va riab le"></p> <p ><input type="submit" name="Subm it" valu e="Submit"> </p> </form > </body> </h tml>. 16.

(21) La lín ea: <form action ="/cgi-bin /matweb.exe" m ethod="POST"> es la en car gada de llam ar el arch ivo ejecutable matweb.exe el cual es el p unto de entrada al MATLAB W eb Serv er. Este archivo m atweb. exe se encar ga de reco lectar la información que ingr ese el usuar io en el formato HTML. La lín ea: <inpu t typ e="hidden " name="m lm file" value="a rchivo .m "> es un campo escon dido en el que se invoca el archivo .m que será el encar gado de controlar las señ ales que serán enviadas a la unidad de interfase y posteriorm ente al Helicóptero CE 150. Es necesar io reem plazar el valor “archivo .m” por el nom bre del archivo .m que se necesite correr. Esta lín ea es utilizada par a pasar las variables que ingrese el usuar io al serv idor en don de correrá el proceso del archivo .m. Desp ués de estas do s líneas, se pueden agregar todas las v ariables que p uede in gresar el usuario. Estas variables se deben in gresar de la forma: <p >Variable: <input type="text" name="nom bre_de_la_variab le"></p > Desp ués de este punto se p ueden ingresar todas las var iables que sean necesarias para poder procesar correctam ente el archivo .m . El valor que se ingrese en “nom bre_de_ la_var iable” será el nombre con el cual se deberá ref erir al valor de esta variable en el archivo .m . Finalmente en el diseño del do cumento de in gr eso de datos debe haber un botón de Subm it, a través del cual el usuario po drá h acer click par a env iar los datos in gr esados al controlador de la pr áctica CE 150. <p ><input type="subm it" nam e="Submit" value="Subm it"></p > Finalmente es necesario cerrar el form ato que se env iará al servidor con las variables que in greso el usuar io para ser procesadas por el archivo .m. Para esto se utiliza la línea: </form> 3.3.1.1.1. Validación. Debido a que el modelo del Helicóptero CE 150 es un in strumento costoso, es importante verificar que lo s datos que sean in gresados en el documento estén dentro de los parám etros perm itidos por las especificaciones del m odelo. Para esto se desarrolló un progr ama de validación en len guaje Jav ascript en el que se evalúa cada variable de ingr eso y se compara con las especificaciones del m odelo. Si la variable ex cede los límites del m odelo, no se enviara la inform ación al controlador de la práctica CE 150 y se le inform ará al usuario cuales son los ran go s permitidos. Hasta que el usuar io no corrija estos errores, la información no será enviada al controlador. 17.

(22) Los límites con lo s cuales serán com paradas las v ariables de entrada depen den del experimento que se vay a a realizar so bre el m odelo CE 150. Para ver cuales son estos límites se p uede referir a la inform ación de la tabla 1. 3.3.1.2. Documento de salida de datos. Una vez se obtengan los r esultado s deseado s del exper imento realizado a través del archivo .m es necesario tener claro cuales son los resultados que se le van a m ostrar al usuario final mediante el documento de salida. El form ato general del docum ento de salida debe ser de la siguiente m anera: <html> <head > <!--En este punto va la in form ación general d e la página- - > </h ead > <body > <!--En este punto se pu ede hacer el diseño d e la página de salida- - > $ variab le_de_ salida $ <im g border=0 src="$ Nombre_arch ivo_gráfico$"> </body> </h tml> La lín ea: $ variab le_de_salida $ es la encargada de m ostrar el valor del resultado que se almacena en el archivo .m en la variable va riab le_de_ salida en caso de que se h aya generado. De no h aber generado ninguna variable que se quier a desplegar en el documento de salida, no es necesario agregar esta línea. En caso de ser m ás de una las var iables que se quieren m ostrar, solo es necesario agregar esta línea el n úm ero de var iables que se n ecesite, asignán dole el nom bre de la variable que vien e del archivo .m en el parámetro variable_de_sa lida. La lín ea: <img border=0 src="$ Nom bre_archivo_g ráfico$ "> es la encar gada de mostrar el gr áfico que se genere en el archivo .m . Es necesario cambiar el parámetro Nombre_archivo_grá fico por el nombr e que se le asigna al gráf ico en el archivo .m. En caso de ser m ás de uno los gráfico s que se quieren m ostrar, solo es necesario agr egar esta línea por el número de gráficos gener ados, asign án dole al parámetro el nombre del archivo que se genera en el ar chivo .m. 3.3.2 Módulo Controlador Práctica CE 150: Estructura general Archivo .m El archivo .m se utiliza para crear el có digo MATLAB que va a estar encar gado de correr la ap licación que controlará el modelo del Helicóptero CE 150. En este ar chivo se toman los valor es que se ingr esaron en el do cum ento de in greso de datos, se. 18.

(23) procesan y se devuelven al do cum ento de salida de datos ya sea como valores o como gráf icos. La estruct ura básica de este ar chivo es la siguiente: PASO 1 Cabezote del archivo .m . Como este archivo .m va a devolver lo s valores calculado s en el proceso, es necesario declarar una f un ción que dev uelv a una cadena con los resultado s. La línea del cabezote debe tener la siguiente estructura: function retstr = arch ivo_m (datos, archivo sal) retstr = es la cadena en la que se van a devolv er lo s valor es de las variables o gráficos al docum ento de salida. archivo_m = es el nombre del archivo que se va a invocar en el docum ento de entrada de datos para que sea ejecutado un a vez se llen en todas las var iables de entrada. Dato s = En este parámetro vienen todo s lo s valor es de las variables del docum ento de ingr eso de dato. Estos datos son caden as de texto. PASO 2 Se debe inicializar la caden a en la que se van a devolv er lo s valor es al docum ento de salida. Esto se h ace p ara borrar toda la información que exista en esta variable de experimentos previo s. retstr = char( ''); PASO 3 En este paso se define cual va a ser la r uta don de se v an a alm acenar los archivo s o gráficos creados dur ante el proceso que se realice en este arch ivo .m. cd(datos.mldir); PASO 4 Obtener las variables que se ingresaron en el do cumento de in greso de datos. Para po der trabajar con el valor que se ingreso en la página HTML de in greso de datos es n ecesario sabe el nombr e de la variable asignado en la página HTML puesto que es así com o se va a identificar en la cadena datos. La instrucción que se debe in gresar para obtener el dato de la var iable es la siguiente: nombre_variable_1 = dato s.nombre_variable_1; En este caso particular, la variable nom bre_variable_1 en el archivo .m tendrá el valor que h aya sido in gresado en el campo de la página HTML que se llam ara 19.

(24) nombre_variable_1. En caso de haber m ás variables de entrada es necesario utilizar esta línea teniendo en cuenta los nom bres asignado s en el documento de entrada. PASO 5 En este paso se deben hacer todo s lo s respectivo s cálculo s y acciones que se deban hacer par a que corr a el experim ento del modelo del Helicóptero CE 150 correctamente. PASO 6 En este paso se deben colocar las v ariables, gráficos, tablas o cualquier tipo de resultado que quiera ser devuelto al do cumento de salida de datos en una estructur a de salida tipo MATLAB. Para esto, se utiliza el siguiente comando: outstruct.variable_de_salida = variable_1; outstruct = nom bre de la cadena donde se van a almacenar to das las variables, gráficos, tablas o cualquier tipo de resultado que quiera mostrarse en la página HTML de salida. variab le_de_ salida = Este parámetro va a ser el nombre que se le va asignar a la variable_1 y con el cual se va a identificar en la págin a HTML de salida. Ver sección 3.3.1.2 para identificar com o se hace para m ostrar este resultado en el documento de salida. variab le_1 = este es el nom bre que tiene la v ariable, gráf ico, tabla o cualquier tipo de resultado que se quiere mostrar dentro del archivo .m . PASO 7 Este es el últim o paso y es en el que se debe llam ar la f unción HTMLREP. A esta función se le pasan com o parámetros, el nom bre del do cum ento HTML de salida de datos que se haya diseñado y se pasa la cadena outstr uct que se generó en el P ASO 6. El có digo para invo car esta f unción es el siguiente: página_salida = which(‘nom bre_página_salida.html’); retstr = htmlrep(outstru ct,página_ salida); En la pr imera lín ea de este có digo se le esta asignan do a la variable página_salida la ruta com pleta en la que se encuentra la p ágina nombre_página_ salida.h tml, esto se hace a través de la f unción wh ich. En la segun da línea de có digo se le esta asign an do al cadena de r etstr, la cual fue iniciada en el PASO 2 el resultado de la fun ción htmlrep la cual le asigna a la págin a que se encuentre asign ada en el parám etro página_salida lo s valores de los resultados, gráficos o tablas que se encuentren en el parámetro outstruct, el cual se explico en el PASO 6.. 20.

(25) 3.3.3 Módulo Web C am El tercer módulo que se va a im plementar en la ar quitectura de v inculación del módulo del Helicóptero CE 150 es el de la Web Cam. Esta cámara estará conectada al serv idor a través de un cable USB y estará ubicada en el mismo lugar don de se ubica el helicóptero CE 150. Por medio de esta cámara el usuario final podr á ver en su aplicación HTML en tiempo real com o se desarro lla la práctica que esta realizando. La cámara que se utilizó es una Lo gitech Clicksm art 310.. 3.3.4 3.3.4.1. C omunicación entre m ódulos Interfaz Hombre/Máquina con Módulo Controlador C E 150. La com unicación entre el m ódulo de interfaz hombre/m áquina y el mó dulo del controlador de la práctica CE 150 se realizo a través de la herramienta MATLAB Web Server. Para que esta herramienta fun cione, fue necesario h acer que la m áquina a la cual estaba conectado el helicóptero CE 150 f uncionara como un servidor. Para esto fue necesario instalar el I BM HTTP Server, el cual es de uso grat uito. El proceso de com unicación entre la págin a HTML y el controlador del Helicóptero CE 150 se hace por medio de la aplicación MATLAB que corre al ser llamada desde la página. Todo este proceso se explico en la sección 3.3.1.1. 3.3.4.2. C ontrolador C E 150 con Unidad de Interfase. El controlador de la práctica CE 150 (archivo .m) se comun ica con la Un idad de Interfase a través de la tarjeta I/O MF614. La com unicación que h ay entre el controlador y la tarjeta se hace por medio del Real Time Toolbox, el cual por m edio de MATLAB envía las señales de control (estímulos DC a lo s m otores) a la tarjeta MF614 quien posteriorm ente envía la señal a la unidad de interfase y esta al modelo del helicóptero CE 150. Par a ver la configur ación de los pines de la tarjeta MF614 y las líneas de control ver el Anexo 7.1.. 3.3.4.3. Módulo Interfaz H om bre/Máquina con la Módulo Web C am. La com unicación que h ay entre estos dos m ódulos se hace por m edio del soft war e W indows Media Enco der. Este software perm ite hacer una con exión desde la págin a HTML con la Web Cam y transmitir lo que se esta o bservan do en esta. El Media Enco der hace una conexión a través del p uerto 1025 del computador y la dirección IP del m ism o para que el usuar io en su página HTML observe en un a aplicación de W indows Media Player el video que se esta transm itiendo.. 3.4. Práct ica propuesta: Contro l PID Elev ación. El modelo del helicóptero CE 150 tiene la facilidad de restrin gir los grado s de libertad del m odelo al asegurar las rotacion es del mismo. Para esta práctica se opto por reducir los grado s de libertad del Helicóptero y hacer todo el exper imento únicamente sobre la. 21.

(26) variable de elevación. Se planteó una práctica en la cual el usuario p uede realizar 3 procedim ientos: •. Diseñar el tipo de estímulo que desea aplicar le al helicóptero CE 150 ya sea para car acterizar la p lanta o para controlarlo.. •. Car acterizar la p lanta aplicando estímulos DC al motor principal.. •. Ingresar los valores de un controlador PID de primer orden y controlar la elevación del m odelo.. Para estas 3 herram ientas de la práctica se desarrollaron los m ódulos de interfaz hombre/m áquina y sus respectivos controladores. 3.4.1. Simulación de Estímulos. Con esta herram ienta el usuario po drá hacer sim ulaciones de lo s estím ulo s que desea aplicarle al sistema ya sea para hacer una caracterización o para aplicar el control PID. Con esta herram ienta el usuario po drá variar los parámetros de la señal de entrada que se ap licara al sistem a. Esta herramienta es de gran utilidad p uesto que si el usuar io genera en ella la entrada que va a aplicar al sistem a, una vez vaya a correr el experimento ya va a estar seguro que la entrada que desea aplicarle al sistema es la correcta. La herr am ienta de sim ulación de estímulos no hace que corra el exper im ento por lo tanto la respuesta es mas ráp ida. 3.4.1.1. Documento de ingreso de datos. Este documento de in greso de datos es una página HTML en don de se le pide al usuario los valores que debe in gresar para generar un estímulo ya sea par a la práctica de caracterización o para la del controlador PID.. Figura 10. Características Generales del estímulo de entrada En la f igura 10 se pueden o bserv ar lo s 7 cam pos que el usuar io debe escoger o m odificar para diseñar su entrada. 22.

(27) Tipo de Estímulo: En este cam po el usuar io podrá escoger entre la opción Niv el DC y Angulo. Al elegir la opción de Nivel DC el usuario estará diseñando un estímulo que po drá aplicar al experimento de caracterización. Al escoger la opción Angulo el usuario estará diseñan do un estím ulo que po dr á aplicar al exp erim ento del control PID. Tipo de Trayectoria : En este cam po el usuario po drá escoger entre las siguientes opciones de trayectorias: • Constante • Escalón • Rectángu lo • Triangulo • Seno • Ruido Tiempo total de sim ulación: En este campo el usuario debe in gresar el tiem po total que se va a dem orar su experimento. Este tiempo debe ser ingresado en segundo s. Va lor medio: En este campo el usuario decide cual va a ser el valor m edio de la señal de entrada. Si la señal de entrada es una con stante, el valor m edio será el que va a determ inar el v alor de la señal constante. Amplitud: Este cam po se ingresa el valor m áximo que p uede alcanzar la m agnitud oscilante de la trayectoria en un p erio do de tiempo. Para el caso de la señal constante, este parám etro no aplica. Periodo: En este campo el usuario po dr á m odificar el tiem po que tar da la señal de entrada en volver al estado o posición que tenía al principio. Para el caso de la señal constante, este parámetro no aplica. Fase: En este cam po el usuario po drá mo dificar la f ase de la trayectoria que ha ingresado. Para el caso de la señal con stante, este parámetro no aplica. La dif erencia entre hacer una sim ulación de un estímulo de un a Señal DC a un estím ulo de An gulo es en la escala que se maneja. Para el exper imento de caracterización la señal de entrada que se le aplique a la planta es una señal DC, cuyo valor oscila entre -1 y 1. Este valor de voltaje es un valor normalizado del voltaje real, cuyo valor máximo alcan za lo s 8 Vo ltios y cuyo valor m ínim o es de -8 Voltios. Esta norm alización es necesaria debido a que la unidad de interfase viene co dificada para interpretar los valores entre -1 y 1. En el caso de que el estím ulo sea un án gulo, se esta haciendo la sim ulación de una entrada p ara la práctica de control. Este ángulo tien e como valor máximo 3 y como valor mínimo -3. Al igual que la señal DC este valor esta normalizado y equivale a 50° y -50° respectivamente.. 23.

(28) En la tabla 5 se p ueden o bservar cuales son lo s lím ites de cada una de las características de un estímulo.. Categ orí a Ti po de Trayectoria. Tiem po Total de Simulación (segundos) Valor Medio Amplitud. Periodo. Fase. Ti po de estí mul o Nivel DC • Con stante • Esca lón • Rectángu lo • Triangulo • Senoidal • Ruido. Angulo • Constante • Escalón • Rectángu lo • Triangulo • Senoidal • Ruido. Valor m ínim o = 1 Valor m áxim o = 50. Valor mínimo = 1 Valor máximo = 50. Valor m ínim o = -1 Valor m áximo = 1 Valor m ínim o = -1 Valor m áxim o = 1 * Es im portante verificar que la suma del valor medio y la amplitud, no excedan los límites. Valor m ínim o = 0 Valor m áxim o = Tiempo total de simulación. Valor m ínim o = -π/2 Valor m áxim o = π/2. Valor mínimo = -3 Valor máximo = 3 Valor mínimo = -3 Valor máximo = 3 *Es importante verificar que la sum a del valor medio y la am plitud, no excedan los límites. Valor mínimo = 0 Valor máximo = Tiempo total de sim ulación. Valor mínimo = - π/2 Valor máximo = π/2. Ta bla 5. Límites perm itido s para las señales de entrada Como se menciona en el punto 3.3.1.1 y en el 3.3.1.1.1, es necesario validar que la información que se esta in gresando en la página HTML contenga toda la información necesaria para realizar la pr áctica y que ésta no so brepase los lím ites de n uestro modelo. Por esto f ue necesario implementar un algoritmo en el que se valida la información que se esta in gresando en la p ágina antes de enviar la al modelo. En la figura 11 se o bserva el algor itmo que se planteó, en el cual se verifica que: •. Todos lo s campos para ingresar lo s datos del estím ulo de entrada ten gan un valor.. •. El valor ingresado sea un v alor num érico.. •. Que el valor ingresado se en cuentre entre los límites p erm itidos por el m odelo.. 24.

(29) El có digo Jav ascript generado p ara validar la información de las características del estím ulo se encuentra en el anexo 7.2. Siguiendo con las esp ecif icaciones del p unto 3.3.1.1, en esta página HTML de in greso de datos se incluyeron las siguientes líneas: <form action ="/cgi-bin /matweb.exe" m ethod="POST" ta rget="outpu twindo w" onsubmit="retu rn ch eckform (this) "> <inpu t type="hidden" nam e="mlm file" value="simulacion"> En la prim era de ellas se esta invocando el archivo mat web.ex e para iniciar la ap licacion en MATLAB. El comando on submit ="return checkform(this) " es el encar gado de llamar la fun ction de validación previo a enviar la inform ación recolectada. En la segun da lín ea, se coloca el nom br e del archivo .m o controlador, en este caso “simulación”, el cual está encar gado de realizar la respectiva sim ulación en MATLAB y de generar el gráfico que será devuelto al usuario para que r evise si la entrada que programó es la deseada. Finalmente, la p ágina HTML de entrada de datos tiene un botón sobr e el cual el usuario puede dar clic y enviar el form ulario diligenciado apropiadamente a la aplicación en MATLAB para que esta corra y genere los r esultado s esperado s. El resultado final de esta págin a (Estímulo s.html) se puede v er en la figura 12.. 25.

(30) Figura 11. Algoritmo de Validación de datos de la señ al de estímulo. 26.

(31) Figura 12. Página HTML de ingreso de datos para la sim ulación de estímulos. 3.4.1.2 C ontrolador Estím ulos: Archivo .m “sim ulación” Una vez se recolectaron las características del estímulo en la página HTML de ingr eso de datos es posible empezar a trabajar con ello s en la herr am ienta MATLAB. Com o se especifico en el formato gener al del controlador o archivo .m en el p unto 3.3.2, los paso s para el diseño de este archivo dieron com o resultado el siguiente có digo: PASO 1 function PageStr ing = sim ulacion(Input Set) PASO 2 PageString = cha r( '');. PASO 3 cd(Inp ut Set.mldir); PASO 4 % parametros de tiem po Tt= str2double(Input Set.Tt);. % Tiem po Total. 27.

(32) % parametros de la trayecto ria Xo1=str2double(Inp utSet.Xo1) ; Xm1=str2 do uble(Inp ut Set.Xm1); to1=str2double(Input Set.to1); phi1=str2do uble(Inp utSet.phi1); tray=InputSet.Trayectoria; estím ulo =Inp ut Set.estím ulo;. % valor m edio % amplitud % periodo % fase % tipo de trayecto ria % tipo de estímulo. PASO 5 El primer paso para po der gener ar el resultado de la sim ulación deseada por el usuario, es definir el tipo de entrada que se va a ap licar so br e el sistem a. Com o este algoritm o se va a repetir par a to dos las po sibilidades que ofrece esta pr áctica (car acterización, práctica de Control), se prop uso el algoritm o general que se encuentra en la f igura 12. En este algoritm o se define que tipo de trayectoria desea el usuario, y un a vez se tenga esta información, depen dien do de la selección se calculan los valores del vector que será la señal de entrada al sistema. Para esta práctica de control, en la herramienta de simulación de entradas se fijo que el tiem po de muestreo fuera 0.1 segun dos, lo cual para una prueba de 25 segun dos de duración, nos gen era un vector de 250 p untos. Para la práctica de caracterización y control PID esta tasa de m uestreo la def ine el usuario. Para ver el có digo en el que se define el tipo de trayectoria, v er anexo 7.3. Desp ués de o btener el vector deseado con todas las características que el usuario in gresa en la página HTML de ingreso de datos, el siguiente paso es el de generar el respectivo gráfico. Para ver el código de generación del gráfico y el de la trayectoria, v er anexo 7.4 PASO 6 En este archivo .m solo estamos generando un gráfico que va a ser mostrado al usuario final. Del m ism o m odo estam os tomando el valor del tipo de estímulo que se v a a realizar para com unicarle al usuar io que tipo de sim ulación se llevo a cabo Para po der enviar el gráfico gener ado, y el tipo de estím ulo es necesar io vincularlo en una estructura en la que se p ueda enviar al págin a HTML de salida de datos. Para esto se utiliza el siguiente có digo: salida. valor=estímulo; salida. GraphFileName = sprintf('estím ulo%s.jpeg', InputSet.mlid); wsprintjp eg(Fig, salida.GraphFileNam e); salida. GraphFileName = sprintf('/icon s/estímulo% s.jpeg', InputSet.m lid); En este caso la estruct ura que se v a a enviar desde el archivo .m (simulacion) hacia la página de salida va a ser s. El nom bre del archivo es estímulo.jpeg el cual se v a a guar dar en la carpeta raíz del servidor. Aparte de generar el resultado gráfico de la simulación, tam bién se genera un archivo en formato Excel, el cual el usuario po drá bajar desde la página de salida de datos para hacer lo s resp ectivos análisis de ser necesario.. 28.

(33) Figura 12. Algoritmo para definir la Trayectoria PASO 7 Se p asa a la página de salida (estímulos2.htm l) el gráfico gener ado por el archivo .m previamente. Este es el código p ara hacer este procedimiento: templatefile = which( 'e stímulos2.html'); PageStrin g = htm lrep(s , tem platefile);. %en este com ando de identifica la ruta de la página Estímulos2.htm l % con este com ando se en vía el gráfico estímulo.jpeg a la página estímulos2.htm l. 3.4.1.3 Documento de salida de datos Este es el documento que llam a al ar chivo .m (sim ulación) .En esta página, se van a m ostrar el gráfico generado durante la sim ulación y se le indicar á al usuario que tipo de estím ulo f ue el que generó. El có digo en don de se referencia la variable de lo s estímulos y el gráfico es el siguiente: <p> El r esultado de su sim ulación de $valor$ f ue exitosa. </p > <img bor der =0 sr c="$Graph FileName$">. 29.

(34) Si miram os el có digo del PASO 6 del p unto 3.4.1.2 po demos ver que la estr uctura de la variable salida, que es la que r eem plaza los valor es en la págin a estímulos2.html tiene la var iable valo r, y el gráfico GraphFileName. El có digo de la p ágina HTML de salida se puede ver en el an exo 7.5; esta estruct ura será utilizada para las páginas de salida de la car acterización y el control PID. De este modo, tanto el gr áfico como el contenido de valor se mostraran en la página de salida de la siguiente m anera:. Figura 13. Página HTML para salida de datos de simulación de estím ulo s 3.4.2. C aracterización de la planta. En esta parte del laboratorio el est udiante podr á caracterizar la p lanta con una señal DC que será aplicada al motor principal del helicóptero como se muestra en la Figura 13. El valor de la señal DC que se le p uede ap licar al sistema oscila entre -1 y 1; éste valor está norm alizado y equiv ale a un voltaje de +/- 8 Voltios. El signo de la señ al determina el sentido en el que gir an las hélices. El est udiante in gresara los valores que se piden en las car acterísticas generales en la página HTML de ingreso de datos y se establecerá una conexión mediante una aplicación de W indows Media Player con la W eb Cam a través de la cual po drá observar com o transcurre la car acterización en v ivo. Una vez el experim ento concluya, 30.

(35) el estudiante recibirá una gr áfica en la que po drá observ ar las m ediciones tom adas del ángulo de elevación del helicóptero y del nivel DC del motor principal a lo largo del experimento. Si el est udiante desea los datos de lo s resultados, po drá bajarlo s en un formato .xls para realizar sus respectivos cálculos.. Figura 13. Modelo del sistem a de Car acterización de la planta 3.4.2.1 Documento de ingreso de datos Este documento tiene el mismo formato que el que se descr ibió en la parte 3.4.1.1. Las dif erencias entre las dos páginas, son: •. Esta página no tiene el par ámetro de Tipo de Estímulo pero tiene el parám etro de Tiempo de M uestreo. •. En esta página esta la aplicación de Windo ws Media Player para observar lo que esta sucediendo a través de la Web Cam.. •. El nombr e del arch ivo .m que v a a gener ar la aplicación en MATLAB se llama es caracterizacion.m. El algoritmo utilizado para validar los datos que se in gresaron es el m ism o planteado en la figura 11 teniendo en cuenta las dif erencias en los par ámetros. Debido a que en este experimento el usuar io p uede in gr esar el v alor de la tasa de m uestreo lo s lím ites para la variable de Tasa de muestreo son lo s siguientes:. Tasa de m uestreo. Trayectoria de Caracterización Valor mínim o = 0.01 Valor máxim o = 0.5 Ta bla 6. Límites de Tasa de muestreo. Estos ran gos se establecieron debido a la lim itación del soft ware y la velo cidad de la m áquina en don de se corría el proceso. Cualquier valor por f uer a de este ran go afectaba el desarrollo del experim ento. 31.

(36) La págin a de ingr eso de datos para la pr áctica de caracterización es la siguiente:. Figura 14. Página HTML de in greso de datos para la caracterización de la planta. Se p uede observar en la figura 14 en la parte central izquier da, los campos que debe llenar el usuario par a gener ar el estímulo que se le va a aplicar a la planta. Se observa claram ente que son iguales a los que se muestran en la figura 10 con las diferencias pequeñas que se m encionaron anteriormente. En la parte infer ior izquier da, esta la aplicación de Windo ws Media Placer por medio de la cual el usuar io podr á lo que esta sucedien do con el m odelo real del helicóptero en tiempo real. Debajo de la aplicación del Windo ws Media Placer se encuentra el botón de “ Submit” por m edio del cual el usuar io dará inicio a su práctica siempre y cuan do los valores que se h ayan in gresado en Características Generales estén dentro de los límites de la práctica.. 32.

(37) 3.4.2.2 Archivo .m: Controlador 3.4.2.2.1. Definición de contadores [10]. Para poder establecer una com unicación entre la aplicación en MATLAB y el módulo del helicóptero CE 150, es necesario utilizar el Real Time Toolbox. En esta herr amienta, la com unicación es sincrón ica y los procesos que se realizan a través de esta son por m edio de los contado res. El contador no solo es un dispositivo que prov ee tiem po, sino que también se utiliza como un objeto par a realizar acciones en tiempo real. Un contador es definido con el com ando rtdef el cual tien e las siguientes conf iguraciones: rtdef (nombre, ‘tipo’,periodo, canal, numerador, d enominador) rtdef(‘va r_hist’,la rgo,ancho) Estas son las dos formas en que se van a usar lo s contadores par a controlar el mo delo. En la pr imera configur ación se define un contador nombre, cuyo tipo p uede ser ‘in’ o ‘out’. Si el tipo es ‘in’ el contador estará encar gado de leer inform ación, mientras que si es ‘ou t’ solo enviara inform ación. El periodo determ ina cada cuanto se v a a enviar o recibir inform ación en este contador. El canal es equivalente a lo s canales de la tarjeta MF614 a través de lo s cuales se va a comunicar con la unidad de interfase. El numerador y denom inador se utilizan en el caso que el contador trabaje como una función de transferen cia, en cuyo caso el tipo puede ser ‘tfin’, ‘ tfout’,’m vtfin’,’mvtfout’ (función de transferencia de entrada, fun ción de transferencia de salida, función de transferencia multivariable de entrada, f unción de transfer encia de salida multivar iable). En la segun da conf iguración, el contador se def ine com o una variable h istórica con nombre var_hist. Con esta configur ación, es po sible asignarle a un contador lo s valores de una variable para que estos sean interpretados com o comando s de in greso par a otros contadores y realizar una acción en tiempo real, o sim plemente se p uede utilizar como una variable en don de se alm acenan los datos que se lean del m undo exterior. Los parám etros de ancho y largo, determ ina las medidas de la variable histórica en caso que esta sea un vector o una matriz. 3.4.2.2.2. C omunicación con los contadores. Una vez se definen los contadores, la forma de ver cuales son lo s valores que estos tienen se hace a través de los com ando s rtwr y rtrd. Por medio de estos comando s es posible escr ibir v alores predeterminados al contador, ya sea asignán dole el valor de una variable en el pro grama o hasta un vector com pleto. Cuan do se utiliza el coman do rt wr, los p arám etros que utilizan esta fun ción son el nombre del contador o variable histórica al cual se desea escribir algo, y el valor que se va a enviar. Cuan do se usa el comando rtrd, es necesario pasar com o parám etro el nombre del contador o variable histórica del cual se desea leer inform ación. Otra facilidad que ofrecen los contadores es que pueden comun icar se entre ellos m ism os, es decir, si un contador es de tipo ‘o ut’, el valor que este escribe p uede ser la entrada de un contador de tipo ‘in’. Com o todos los contadores funcionan sincrónicamente, es posible realizar esta conexión sin nin gún pro blema; no obstante, es. 33.

(38) im portante tener en cuenta que los periodo s de m uestreo y lo s tamaños de estos deben coincidir. 3.4.2.2.3 Módulo de tiem po real Debido a que este archivo .m tiene car acterísticas sim ilares al archivo .m de sim ulación vamos a hacer énfasis en el PASO 5, que es don de se establecer á la comun icación con la interfase del helicóptero CE 150. El procedimiento realizado par a la gener ación del vector de la trayectoria es el m ism o que se utilizó en el archivo de sim ulación y es el que esta descr ito en la f igura 12. Una v ez se o btiene este vector, es n ecesario asignar lo a un contador 1 que tenga las características de una variable histórica. Este contador 1 debe ser de tipo ‘in’ y debe tener el mismo tam año al generado por el algoritm o de trayectoria. Este contador 1 debe conectarse por con un contador 2 de tipo ‘out’ que establezca conexión con la señal que controla el nivel DC del helicóptero CE 150 (esta comunicación se hace a través del can al 6 de la tarjeta MF614). La lectura del án gulo de elevación que no s proveen los contador es incrementales ubicado s en el h elicóptero, se envía desde la un idad de interfase a la tarjeta MF614 por medio del canal 3. De este m odo es necesario cr ear contador 3 con características de un a variable histórica, en el cual se va a alm acen ar cada m edida que sea enviada por la unidad de interfase. To dos estos contadores deben tener el mismo per iodo de m uestreo y es aquel que determine el usuario en la página de ingreso de datos.. 34.

(39) Figura 15. Algoritm o del m ódulo de tiem po real de caracterización. Teniendo la asignación de los contadores completa, es posible corr er el experim ento iniciando lo s contadores sim ultáneamente. Lo s resultados del exp erim ento serán almacenados en la variable histórica del contador 3. Este archivo .m de caracterización genera un gráfico en el que se m uestra el án gulo de elevación del helicóptero en el tran scur so del exp erim ento. Este gráfico se le m uestra al usuario en la página HTML de lo s resultados y por lo tanto se debe realizar el mismo procedim iento que se h izo en el archivo .m de sim ulación en los P ASOS 6 y 7 en donde se gener a una estr uctura que se pueda enviar a la págin a HTML de salida (caracterizacion2.html). El có digo del archivo .m de car acterización esta en el anexo 7.6. 3.4.2.2.4. Documento de salida de datos. La estructura de este docum ento es igual al documento de salida de la sim ulación de estím ulo s. El usuario podrá v er en la página lo s resultados del exper im ento de 35.