Proyecto de Grado

Laboratorio a distancia: Módulo de control Helicóptero CE 150

Julian Sanclemente Mansilla

Asesor: Mauricio Guerrero

UNIVERSIDAD DE LOS ANDES DEPARTAMEN TO DE INGENIERÍA ELÉC TRIC A Y ELEC TRÓNIC A PRO YEC TO DE GRADO 2005

Resumen En este proyecto de grado se implementó una práctica de control, basada en el modelo del Helicóptero CE 150, para el laboratorio a distancia de la Universidad de Los Andes (ULA) para apoyar la formación en el área de control. Esta práctica consiste en aplicar un sistema de control PID al helicóptero a través de la herramienta MATLAB, para que pueda ser utilizado desde cualquier computador conectado a Internet. La aplicación es educacional y podrá ser utilizada por cualquier persona interesada en esta área. Al tener esta ap licación en la red, se podrá pensar en la opción de soportar cursos a distancia, brindar este servicio a otras instituciones y así mismo compartir 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.

i

Tabla de Contenido 1. Introducción ...............................................................................................................1

1.1 Objetivos ...........................................................................................................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 instrumentación para el desarrollo de laboratorios a distancia y manejo de instrumentos [1]. ....................................................................2 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].........................................................................................4

2.2 Antecedentes Externos ......................................................................................5 2.2.1 MIT Weblab ( iLab)[4] ...............................................................................5 2.2.2 A DIstant Reality Enviroment for Control Teach ing (DIRECT) [7] ........7

3. Desarrollo ..................................................................................................................8 3.1 Estudio del modelo [8] ......................................................................................8

3.1.1 Especificaciones del helicóptero ...............................................................9 3.1.2 Especificaciones de la unidad de interfase y la tarjeta I/O MF614 .........10 3.1.3 Dimensiones y pesos ...............................................................................10

3.2 Alternativas de control ....................................................................................11 3.2.1 GPIB........................................................................................................11 3.2.2 Soft ware prop io .......................................................................................11 3.2.3 MATLAB [9] ..........................................................................................11

3.3 Arquitectura propuesta ....................................................................................13 3.3.1 Módulo interfaz/hombre: 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: Estructura general Archivo .m ..18 3.3.3 Módulo Web Cam ...................................................................................21 3.3.4 Comunicación entre módulos ..................................................................21

3.3.4.1 Interfaz Hombre/Máquina con Módulo Controlador CE 150 .............21 3.3.4.2 Controlador CE 150 con Unidad de Interfase .....................................21 3.3.4.3 Módulo Interfaz Hombre/Máquina con la Módulo Web Cam ............21

3.4 Práctica propuesta: Control PID Elevación .....................................................21 3.4.1 Simulación de Estímulos .........................................................................22

3.4.1.1 Documento de ingreso de datos...........................................................22 3.4.1.2 Controlador Estímulos: Arch ivo .m “simulación” ..................................27 3.4.1.3 Documento de salida de datos .............................................................29

3.4.2 Caracterizació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 Comunicación con los contadores .................................................33

ii

3.4.2.2.3 Módulo de tiempo 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 Opciones de capt ura de v ideo ..................................................................43

3.5.1.1 Windows Media 9 Series [11] .............................................................43 3.5.1.2 Camstudio [12] ....................................................................................43 3.5.1.3 Webcam Watchdog [13] ......................................................................43

4 Conclusiones ...........................................................................................................44 5 Perspectivas .............................................................................................................45 6 BIBLIOGRAFIA.....................................................................................................47 7 ANEXOS.................................................................................................................48

7.1 Información técnica del cableado de la tarjeta MF614 ...................................48 7.2 Código Javascript de Validación .....................................................................50 7.3 Código para def inir vector de Trayectoria ......................................................52 7.4 Código para generar gráfico de sim ulación de Estímulos ...............................53 7.5 Código HTML de la página de salida de Estímulos........................................53 7.6 Código de arch ivo .m de caracterización ........................................................53 7.7 Código de función que convierte controlador continuo a polinomio discreto 58 7.8 Código de arch ivo .m de control PID..............................................................58

1. Introducción

En la educación de hoy día, las prácticas experimentales son un factor importante para el desarro llo académico de cualquier estudiante, ya que a través de ellas se crea la conexión entre los conceptos teóricos y la realidad. Actualmente en la ULA se desarro llo una propuesta de un Laboratorio a Distancia y se dio in icio a dicha actividad con el desarrollo de un sistema general de interconex iones configurable remotamente que une instrumentos de medición con algunas prácticas. El objetivo principal de este laboratorio es poder ofrecer al estudiante la posibilidad de aproximarse a experiencias reales las cuales contribuyen al desarrollo integral e intelectual de la persona mediante la utilización de tecno logías modernas de información, así como la f lexibilidad ofrecida por Internet. Este laboratorio a distancia que se esta desarrollando permitirá mejorar aspectos como:

• La ocupación de puestos de trabajo en un laboratorio. • El tiempo representado en tener que asistir físicamente al laboratorio para

cualquier estudiante.

• El alto costo que implica ofrecer un espacio de trabajo y un asistente permanente.

• Mayor utilización de equipos costosos con los cuales no es viable hacer

laboratorios permanentes masivos. La solución de estos problemas a través de la implementación de la nueva práctica y el laboratorio a distancia, ofrecen beneficios como aumentar el número de prácticas disponibles, el uso eficiente de recursos, la activa participación de más est udiantes, y por supuesto facilita la creación de una p lataforma complementaria de conocimiento. En este proyecto se va a realizar un estudio detallado de la propuesta y avance del laboratorio a distancia que se esta desarrollando actualmente en la ULA y se vinculara una práctica en el área de control utilizando el modelo del Helicóptero CE 150. 1.1 Objetivos

1.1.1 Objetivos Generales

• Integrar el módulo de control: Helicóptero CE 150 al laboratorio a

distancia de la Universidad de Los Andes. • Ampliar el rango de prácticas disponibles en la Universidad de los Andes

en el área de control.

2

1.1.2 Objetivos Es pecíficos

• Diseñar e implementar una interfase de usuario final a través de la cual

persona conectada a la red podrá tener acceso a la práctica del Helicóptero CE 150.

• Diseñar e implementar el soft ware encargado de manejar la práctica del

helicóptero. Este estará encargado de interpretar las señales que envía el usuario por medio de la interfase final y comunicárselas al Helicóptero CE 150 como señales de control.

• Poder mostrar el desarro llo del exper imento 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 objetivo principal diseñar la arquitectura base del laboratorio a distancia de la ULA. En el diseño de esta arquitect ura se planteó una p lataforma que permitirá que el usuario pueda realizar mediciones y conf iguraciones de diferentes dispositivos por medio de Internet utilizando el protocolo GPIB como base. Todos los instrumentos que se utilizaran en este laboratorio deben usar el protocolo GPIB al igual que las prácticas que vayan a ser conectadas. En la Figura 1 se puede observar el resultado final de la arquitectura base diseñada en este proyecto. En esta podemos observar que el diseño general del laboratorio se puede div idir en 3 bloques. El primer 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 Hombre/Máquina. En el segundo bloque se encuentra el servidor, el cual es el encargado de controlar el laboratorio a distancia. En este bloque se llevaran a cabo procesos como: manejo de clientes, validación de usuarios, manejo de colas y turnos, accesos a las bases de datos, y los controles de configuración. Este servidor recibirá la información entrante de los clientes por las conex iones TCP/IP, procesara la información y la comunicara a los respectivos instrumentos o prácticas conectadas por medio del el bus GPIB El tercer bloque del laboratorio lo componen los instrumentos y las prácticas conectadas al bus GPIB por medio del sistema de interconexiones. Este sistema de interconexiones es el encargado de recibir la información enviada por el serv idor por el bus GPIB y

3

hacer las conexiones respectivas entre la práctica deseada y los instrumentos que deben tomar los datos. El protocolo permite que el controlador sea capaz de realizar hasta 15 conexiones con distintos dispositivos de medición con una tasa de transferencia de 1Mbyte por segundo (valor nominal). La longit ud de los cables puede ser de 20 metros entre el controlador y el principio del bus (8 bits) y de 2 metros entre los instrumentos. Es importante mencionar que en este sistema las prácticas también son consideradas como instrumentos. En caso tal que todos los instrumentos se encuentren conectados al sistema de interconex ión, el laboratorio a distancia podría manejar un total de 8 prácticas.

Practicas

Servidor

Internet

Cli ente 4

Cl iente 5

Cliente 6

Modem

Tarjeta GPIB

Ethernet

Cli ente 2

Osciloscopio

Sistema de Interconex ion

Gen . Señales

Pract ica 1Prac. 2

Cli ente 1Cliente 3

Servidor

Cl iente

Mult im et ro

Manejo GPIB

M anejo Clientes

Control del Servidor

Base de Datos

Prac. 4 Prac. 6

Prac. 3 Prac. 5

Vol tim et roFuente DC

Bus GPIB

Conexion Remota

Interfaz Hom bre-Maquina

LABORATORIO A DISTANCIA DE LA UNIVERSIDAD DE LOS ANDES

Instrumentos

Figura 1. Diagrama general del laboratorio a distancia de la ULA

Los instrumentos que se tienen act ualmente en el laboratorio a distancia y los cuales pueden ser configurados mediante los controladores del fabricante y el sistema de interconexión son:

• Osciloscop io TDS Ser ie 1000.

• Multímetro FLUKE 8500 A.

• Voltímetro HP 3437 A.

4

• Fuente de voltaje y de corr iente

• Generador de funciones HP 3325 A.

• Analizador HP 8590

• Analizador de redes HP 8753

Algunos de los instrumentos mencionados anteriormente no tenían los controladores diseñados por los fabricantes, por esto algunos controladores fueron diseñados e implementados. Estos controladores programados en Visual Basic permiten la comunicación de los instrumentos con el sistema general. El sistema de interconexión diseñado en este proyecto de grado fue probado y funciono correctamente. Se implementó un diseño básico de servidor el cual configuraba el sistema de interconexiones para tomar unas medidas de una práctica sencilla. 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 complemento al antecedente mencionado en [1]. El objetivo principal de este proyecto fue desarrollar un módulo de prácticas que podían ser configuradas mediante el protocolo GPIB y a la vez desarrollar una interfase vía Internet para el usuar io del laboratorio. Inicialmente 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 parche para 2.4 GHz, y un módulo PID. El diseño de las prácticas fue completado, pero so lo se implementó físicamente 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 Leyes Básicas Eléctricas

5

El diagrama de bloques de la práctica consta de 3 bloques pr incipales. La interfaz GPIB la cual esta conectada con el bus GPIB, encargada de recibir lo s comandos que se son enviados desde el servidor y traducir los en comandos de 2 bytes que serán transmitidos al segundo bloque. El bloque que esta en la parte inferior a la interfaz GPIB es el bloque de interfaz con JTAG, el cual esta encargado de hacer la respectiva programación del bloque de la interfaz GPIB (CPLD de Xilinx XC9572). El segundo bloque de esta práctica consta de los módulos de Unidad de control de la práctica y el módulo Programador de la unidad de control. El primero (microcontrolador de Microch ip 16F877) es el encargado de recibir los comandos de la interfaz GPIB e interpretarlos ya sea para configurar la práctica de cierta forma o para cambiar los parámetros de los elemento que la componen. El segundo módulo es el que permite programar el módulo de control. El tercer bloque es la práctica de Leyes básicas eléctricas. En este módulo hay un puente de resistencias compuesto por 6 resistencias digitales, 6 interruptores y una fuente. En la figura 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á configurar las prácticas y ajustar los parámetros de los elementos que la componen.

2.2 Antecedentes Externos 2.2.1 MIT Weblab (iLab)[4]

En la un iversidad de MIT se ha venido desarro llando un laboratorio virtual desde junio del 2000 hasta hoy día. Los primeros 3 años del proyecto se intentó proveer acceso en línea a un laboratorio remoto, el cual debido a costo, espacio y otras razones no se había montado. Otro objetivo en esta primera fase era la de entregar los beneficios

6

educacionales de las prácticas experimentales a los est udiantes en cualquier lugar y a cualquier hora. En la segunda fase, es decir en el último año, fue de desarrollar un software lo suficientemente estable y avanzado como para crear una infraestruct ura sólida de los laboratorios virtuales. Actualmente basados en las experiencias ex itosas que han tenido con los experimentos realizados, este software está en una fase bastante avanzada. El soft ware se llama Service Broker versión 5.1. Para implementar este nuevo soft ware se tomo como arquitectura base la que se muestra en la Figura 4.

•

Figura 4. Arquitectura iLabs [4] El diseño de iLabs divide las prácticas remotas en tres módulos que son conectados por la arquitect ura del Web Lab.

• El servidor del Weblab es operado por la gente en MIT y se encarga del manejo de todos los elementos Hardware 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 operación con el laboratorio.

• El iLab Service Broker es el encargado de recibir la información de la aplicación del usuario y los Lab Servers. A la vez esta encargado de proveer el servicio de almacenamiento de datos, servicios administrativos los cuales son genéricos y que pueden ser compartidos por varios laboratorios al tiempo dentro de la misma universidad.

7

Este Weblab de MIT funciona actualmente y presenta más de 7 prácticas exper imentales en línea entre las que se encuentran:

• Microelectronics WebLab • Chemical reactor

• Mechanical struct ures • Heat exchanger • Instrumentalized flagpo le • Shaker table • Polymer recrystallization • Photo voltaic weather station

2.2.2 A DIstant Reality Envirom ent for Control Teaching (DIREC T) [7] El objetivo principal de DIRECT es crear un ambiente que permita que los estudiantes aprendan técnicas de diseño de control básicas y que puedan probarlas por medio de simulaciones y pruebas reales en una planta física distante. El estudiante puede hacer sus diseños de los controles en herramientas como 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 remoto. Hasta el momento DIRECT tiene 2 exper imentos los cuales son un péndulo invertido y un motor DC. La arquitect ura básica de este laboratorio se puede observar en la Figura 5.

Figura 5. Arquitectura general DIRECT [7]

8

En esta arquitectura se plantea como solución tener 4 módulos encargados de manejar el laboratorio, 3 de ellos 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 encargado de guiar al estudiante durante la práctica. Cualquier duda que el estudiante tenga con algún parámetro de ingreso 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 experimentos que se ofrecen en el laboratorio. También es el encargado de dar los accesos de los estudiantes al servidor que controla los experimentos. Otra tarea que realiza este módulo es controlar que los exper imentos este funcionando de manera apropiada. El cuarto módulo es el servidor Experiment. Este servidor esta encargado de recibir la información que v iene del usuario, procesar la y env iarla a los experimentos f ísicos. A la vez esta encargado de recolectar la información obtenida durante la práctica y enviársela al estudiante. 3. Desarrollo 3.1 Estudio del modelo [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 modelación dinámica, identificación, análisis y varios sistemas de control diseñados tanto por métodos clásicos como modernos. El modelo CE 150 consta de 2 motores DC que son los encargados del movimiento de las hélices. El cuerpo del helicóptero puede moverse en 2 grados de libertad; la hélice principal es la que controla el movimiento vertical y la hélice secundar ia el movimiento horizontal. Existe un tercer servo-motor el cual es el encargado de controlar el centro de gravedad del helicóptero, desplazando un peso que se encuentra en el eje del helicóptero. Al mover el centro de gravedad de nuestro modelo podemos cambiar las características de la planta lo cual permite la posibilidad de generar variaciones para las prácticas con el mismo instrumento.

9

Figura 6. Foto del Helicóptero CE 150

El modelo del helicóptero es un sistema dinámico multivar iable con 3 entradas (ángulo de elevación, ángulo de azimut, centro de gravedad) que pueden ser modificadas y 2 salidas que son la lectura de los ángulos en los que se encuentra el sistema. A la vez, el modelo permite la posibilidad de observar las var iaciones de los niveles DC de los 2 motores. En la Figura 7 se puede observar el modelo del sistema con sus entradas y salidas.

Figura 7. Modelo del sistema multi-var iable [8]

3.1.1 Especificaciones del helicóptero El modelo del Helicóptero CE 150 incluye:

• El helicóptero sobre un soporte.

10

• 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 50° en elevación 160° en azimut

Hélice pr incipal 200/100 en directo Hélice secundaria 100/60 en directo Motor Principal DC con imanes permanentes

Voltaje máximo: 12V , 0-6 A Velocidad máximo: 9000 RPM

Motor secundario DC con imanes permanentes Voltaje máximo: 6V , 0-4 A Velocidad máximo: 12000 RPM

Movimiento del centro de gravedad

Servo motor autónomo PWM

Medición de Ángulos Contadores incrementales

Tabla 1. Caracterí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 características:

Adquisición de Ángulos Lógica de contadores incrementales Amplificadores de potencia Servo-amplif icadores PWM DC,

0-240W,12V

Tabla 2. Características de la unidad de interfase

La tarjeta multifuncional I/O MF614 tiene 8 canales conversores A/D, 4 conversores D/A de 12 bits, 4 entradas para encoders, 4 contadores/timers, 8 entradas digitales TTL y 8 salidas digitales TTL. Dos de los timers son utilizados para el control PWM de las hélices del helicóptero. Un timer es utilizado para controlar el centro de gravedad. Las entradas de los encoders y las entradas digitales son utilizadas para las señales de control del sistema. 3.1.3 Dimensiones y pesos Cuerpo del Helicóptero:

Longitud 300 mm (sin hélices) 360 mm (con hélices)

Soporte del modelo Base cuadrada de 300 x 300 mm Altura Máxima 510 mm Peso 3.5 Kg.

Tabla 3. Dimensión y peso del helicóptero

11

Unidad de interfase:

Dimensión 450 x 320 x 155 mm Peso 6 Kg.

Tabla 4. Dimensión y peso de la unidad de interfase

3.2 Alternativas de control 3.2.1 GPIB La primera opción que se estudio para manejar el Helicóptero CE 150 fue a través del protocolo GPIB ya que era el utilizado hasta ahora en el laboratorio a distancia. Para poder controlar el helicóptero con comandos GPIB era necesar io diseñar un dispositivo hardware que se conectara al bus GPIB, y se comunicara con la unidad de interfase de la práctica. Una de las razones por la cual se descartó esta opción es porque el diseño e implementación de este hardware cambiaría totalmente los objetivos de este proyecto de grado y no se lograr ía completar la práctica de control PID debido a la restricción de tiempo. 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 puede instalar en el puerto PCI de cualquier computador la cual se comunica directamente con la unidad de interfase y permite controlar el Helicóptero CE 150. 3.2.2 Software propio El modelo CE 150 viene con un soft ware propio en el cual están dos controladores PID encargados de manejar los motores de elevación y azimut. El usuario puede ingresar los parámetros de los controladores e iniciar el experimento y observar los resultados en tiempo real de las mediciones de los ángulos de respuesta. Las entradas al sistema pueden ser configuradas y modif icadas en el transcurso del experimento. Esta alternativa de control sin duda era bastante interesante y cumplía con las necesidades básicas de la práctica de control deseadas. Aunque esta herramienta ofrece una interfase amigable para controlar el dispositivo, el propósito de este software principalmente es de demostración del modelo y no es posible alterar el código de la misma para poder utilizarla desde un lugar remoto. Por esta razón esta herramienta no cumplía con los requerimientos mínimos del proyecto y fue descartada. 3.2.3 MATLAB [9] Este modelo educacional permite ser controlado a través de la herramienta MATLAB y su Real time toolbox (RTT). Debido a las ap licaciones de este toolbox, MATLAB puede conectarse con el mundo real, teniendo así la capacidad de adquirir información en tiempo real, procesándola con comandos básicos de la herramienta, y finalmente

12

devo lviéndo los al mundo exterior. El RTT es quien nos permite utilizar el controlador de la tarjeta I/O (M F614) del helicóptero para poder conectarnos así desde el computador y la herramienta, con la unidad de interfase encargada de env iar las señales de control a la práctica. MATLAB a su vez, tiene una herramienta 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álculos y poder mostrar los resultados en un Web browser. El MATLAB Web Server se comunica a través de TCP/IP entre el cliente y la aplicación. [9]. Para poder establecer la comunicación entre el cliente y nuestra práctica es indispensable el uso de la herramienta MATLAB; sin embargo, no es un requisito que el cliente tenga instalado este soft ware en su máquina, lo cual nos permite explotar las herramientas del soft ware sin necesidad que los usuarios adquieran la licencia de éste. En la figura 8 se puede observar como ser ia la configuración para correr las ap licaciones en MATLAB desde cualquier computador que se encuentre en la red.

Figura 8. Configuración de aplicaciones Podemos observar 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 puede enviar la información necesaria a una máquina en donde correrán los procesos de MATLAB, el MATLAB Web Server y el servidor (HTTPD). Esta máquina estará conectada al modelo del Helicóptero CE 150 y será la encargada de enviar las señales de control a la unidad de interfase mediante la tarjeta MF614. Todos los resultados y mediciones que se tomen durante el experimento serán devueltos al usuario f inal y el lo s podrá observar a través del Web Browser. Para poder correr una aplicación en el MATLAB Web Server, se debe tener una combinación de archivos .m, lenguaje HTML y gráf icas. El desarrollo de una aplicación con esta herramienta requiere de los siguientes pasos de diseño :

13

• Diseñar un documento HTML que sea el encargado de recolectar toda la información necesaria para correr los procesos de cálculos en MATLAB.

• Diseñar un documento HTML que reciba los resultados procesados por

MATLAB y los muestre al usuario f inal. (Para el diseño de estos documentos se puede usar cualquier herramienta de diseño de páginas HTML).

• Crear un archivo de configuración en donde se incluya el nombre y toda la

información básica de la aplicación que se va a correr en MATLAB (archivo matweb.conf).

• Escr ibir un archivo .m en MATLAB que tenga las siguientes características:

Reciba los datos que fueron ingresados en el documento HTML

Analice los datos de ingreso, corra cualquier proceso necesario y genere

las gráficas respectivas en caso de ser necesario.

Coloque toda la información que va a ser devuelta al usuario en una estructura de salida de MATLAB.

Llame a la función htmlrep, la cual es encargada de llamar al documento

HTML donde el usuar io final podrá v isualizar los resultados. La cantidad máxima de información que se le puede env iar a este documento HTML es de 256Kb

Debido a las facilidades y ventajas que nos ofrece la opción de MATLAB y sabiendo que la Universidad de los Andes tiene licencias de este soft ware, se tomo la decisión de que MATLAB sería la herramienta que se va a utilizar para controlar nuestro modelo el Helicóptero CE 150. 3.3 Arquitectura propuesta El primer paso en la etapa de diseño para vincular el módulo de control al laboratorio a distancia de la ULA fue estudiar a fondo la arquitectura básica que esta planteada en la figura 1. Se determinó que era necesario utilizar el mismo servidor que ya existía y el cual estaba controlando el bus GPIB que maneja todas las prácticas. Debido a que el modelo del Helicóptero CE 150 utiliza un dispositivo hardware diferente a la tarjeta GPIB utilizada por las otras prácticas del laboratorio a distancia, y el servidor tiene el puerto PCI disponible para adicionar este hardware no hay mayor problema de compatibilidad en la integración de la práctica de control al sistema hardware del servidor. A nivel de soft ware, según la arquitect ura propuesta en [1] y [2], cada instrumento 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 todos estos controladores independientes y se comunica con la tarjeta GPIB que

14

enviará los respectivos comandos a través del bus a las prácticas o instrumentos. Por esto se pensó que la práctica del Helicóptero CE 150 debía tener su propio controlador. Como 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 instrumentos controlados por GPIB y estos pueden correr simultáneamente, a nivel de soft ware tampoco hay ningún problema en la vinculación del módulo de control. Teniendo en cuenta que no habrá ningún problema a nivel soft ware ni hardware con la vinculación del módulo del Helicóptero CE 150, y teniendo en cuenta todas las características necesarias para poder correr una aplicación en el MATLAB Web Server se llegó al diseño de una arquitect 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 observar 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 encargado de manejar todo lo correspondiente a la asignación de turnos, a guardar la información reco lectada por las prácticas en una base de datos y a autorizar a los estudiantes a realizar los respectivos experimentos. No obstante, podemos observar que el controlador de la práctica CE 150 va a ser completamente independiente del resto de controladores.

15

Figura 9. Arquitectura de vinculación propuesta

16

Este controlador de la práctica CE 150 debe tener las características mencionadas en el punto 3.2.3. Este controlador será el encargado 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 termine el experimento, el controlador estará encargado de recibir los resultados tomados por la unidad de interfase y los procesara para enviarlos posteriormente al usuar io en un gráf ico. En el momento que se diseño la arquitectura de la práctica del helicóptero CE 150 se concluyo que es de vital importancia que el usuario pueda observar que esta sucediendo mientras transcurre la práctica que se este implementando. Por esto se agrego a la arquitectura una Web Cam que se conecta al servidor por medio del puerto USB y la cual se conectara con la interfaz hom bre/máquina para transmitir en tiempo real los movimientos y respuestas del helicóptero a los comandos programados en el experimento. Esto le dará al usuario la sensación de estar presente en el laboratorio donde están transcurriendo los hechos. 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 experimento que se vaya a realizar sobre el modelo del helicóptero CE 150 corra bien. Para esto el encargado de diseñar la página puede utilizar cualquier herramienta de programación por ejemplo 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ómodo. Dentro del código básico del documento de ingreso de datos hay ciertas líneas básicas que deben estar incluidas dentro del cuerpo de la página HTML para que se pueda correr la ap licación en MATLAB. Este es el formato general que debe tener dicho documento:

<html> <head> <!--En este punto va la in form ación básica de la página- -> </head> <Validación de datos> <body> <form action="/cgi-bin/m atweb.exe" method="POST"> <input type="hidden" nam e="mlmfile" value="archivo .m"> <p>Variable: <input type="text" name="nombre_de_la_variab le"></p> <p><input type="submit" name="Subm it" value="Submit"> </p> </form > </body> </h tml>

17

La línea: <form action="/cgi-bin /matweb.exe" m ethod="POST"> es la encargada de llamar el arch ivo ejecutable matweb.exe el cual es el punto de entrada al MATLAB Web Server. Este archivo matweb.exe se encarga de reco lectar la información que ingrese el usuar io en el formato HTML. La línea: <inpu t type="hidden" name="m lm file" value="archivo .m "> es un campo escondido en el que se invoca el archivo .m que será el encargado de controlar las señales que serán enviadas a la unidad de interfase y posteriormente al Helicóptero CE 150. Es necesar io reemplazar el valor “archivo .m” por el nombre del archivo .m que se necesite correr. Esta línea es utilizada para pasar las variables que ingrese el usuar io al serv idor en donde correrá el proceso del archivo .m. Después de estas dos líneas, se pueden agregar todas las variables que puede ingresar el usuario. Estas variables se deben ingresar de la forma: <p>Variable: <input type="text" name="nom bre_de_la_variab le"></p> Después de este punto se pueden ingresar todas las var iables que sean necesarias para poder procesar correctamente el archivo .m. El valor que se ingrese en “nombre_de_ la_var iable” será el nombre con el cual se deberá referir al valor de esta variable en el archivo .m. Finalmente en el diseño del documento de ingreso de datos debe haber un botón de Submit, a través del cual el usuario podrá hacer click para env iar los datos ingresados 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 formato que se env iará al servidor con las variables que ingreso 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 instrumento costoso, es importante verificar que los datos que sean ingresados en el documento estén dentro de los parámetros permitidos por las especificaciones del modelo. Para esto se desarrolló un programa de validación en lenguaje Javascript en el que se evalúa cada variable de ingreso y se compara con las especificaciones del modelo. Si la variable excede los límites del modelo, no se enviara la información al controlador de la práctica CE 150 y se le informará al usuario cuales son los rangos permitidos. Hasta que el usuar io no corrija estos errores, la información no será enviada al controlador.

18

Los límites con los cuales serán comparadas las variables de entrada dependen del experimento que se vaya a realizar sobre el modelo CE 150. Para ver cuales son estos límites se puede referir a la información de la tabla 1. 3.3.1.2 Documento de salida de datos Una vez se obtengan los resultados deseados del exper imento realizado a través del archivo .m es necesario tener claro cuales son los resultados que se le van a mostrar al usuario final mediante el documento de salida. El formato general del documento de salida debe ser de la siguiente manera:

<html> <head> <!--En este punto va la in form ación general de la página- -> </head> <body > <!--En este punto se puede hacer el diseño de la página de salida- -> $ variab le_de_salida $ <im g border=0 src="$Nombre_arch ivo_gráfico$"> </body> </h tml>

La línea:

$ variab le_de_salida $ es la encargada de mostrar el valor del resultado que se almacena en el archivo .m en la variable variab le_de_salida en caso de que se haya generado. De no haber generado ninguna variable que se quiera 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 mostrar, solo es necesario agregar esta línea el número de var iables que se necesite, asignándole el nombre de la variable que viene del archivo .m en el parámetro variable_de_sa lida. La línea:

<img border=0 src="$Nom bre_archivo_gráfico$"> es la encargada de mostrar el gráfico que se genere en el archivo .m. Es necesario cambiar el parámetro Nombre_archivo_grá fico por el nombre que se le asigna al gráf ico en el archivo .m. En caso de ser más de uno los gráficos que se quieren mostrar, solo es necesario agregar esta línea por el número de gráficos generados, asignándole al parámetro el nombre del archivo que se genera en el archivo .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 encargado de correr la ap licación que controlará el modelo del Helicóptero CE 150. En este archivo se toman los valores que se ingresaron en el documento de ingreso de datos, se

19

procesan y se devuelven al documento de salida de datos ya sea como valores o como gráf icos. La estruct ura básica de este archivo es la siguiente: PASO 1 Cabezote del archivo .m. Como este archivo .m va a devolver los valores calculados en el proceso, es necesario declarar una función que devuelva una cadena con los resultados. La línea del cabezote debe tener la siguiente estructura: function retstr = arch ivo_m (datos, archivosal) retstr = es la cadena en la que se van a devolver los valores de las variables o gráficos al

documento de salida. archivo_m = es el nombre del archivo que se va a invocar en el documento de entrada

de datos para que sea ejecutado una vez se llenen todas las var iables de entrada.

Datos = En este parámetro vienen todos los valores de las variables del documento de

ingreso de dato. Estos datos son cadenas de texto. PASO 2 Se debe inicializar la cadena en la que se van a devolver los valores al documento de salida. Esto se hace para borrar toda la información que exista en esta variable de experimentos previos. retstr = char( ''); PASO 3 En este paso se define cual va a ser la ruta donde se van a almacenar los archivos o gráficos creados durante el proceso que se realice en este arch ivo .m. cd(datos.mldir); PASO 4 Obtener las variables que se ingresaron en el documento de ingreso de datos. Para poder trabajar con el valor que se ingreso en la página HTML de ingreso de datos es necesario sabe el nombre de la variable asignado en la página HTML puesto que es así como se va a identificar en la cadena datos. La instrucción que se debe ingresar para obtener el dato de la var iable es la siguiente: nombre_variable_1 = datos.nombre_variable_1; En este caso particular, la variable nom bre_variable_1 en el archivo .m tendrá el valor que haya sido ingresado en el campo de la página HTML que se llamara

20

nombre_variable_1. En caso de haber más variables de entrada es necesario utilizar esta línea teniendo en cuenta los nom bres asignados en el documento de entrada. PASO 5 En este paso se deben hacer todos los respectivos cálculos y acciones que se deban hacer para que corra el experimento del modelo del Helicóptero CE 150 correctamente. PASO 6 En este paso se deben colocar las variables, gráficos, tablas o cualquier tipo de resultado que quiera ser devuelto al documento de salida de datos en una estructura de salida tipo MATLAB. Para esto, se utiliza el siguiente comando: outstruct.variable_de_salida= variable_1; outstruct = nombre de la cadena donde se van a almacenar todas 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ágina HTML de salida. Ver sección 3.3.1.2 para identificar como se hace para mostrar este resultado en el documento de salida.

variab le_1 = este es el nom bre que tiene la variable, gráf ico, tabla o cualquier tipo de

resultado que se quiere mostrar dentro del archivo .m. PASO 7 Este es el último paso y es en el que se debe llamar la función HTMLREP. A esta función se le pasan como parámetros, el nombre del documento HTML de salida de datos que se haya diseñado y se pasa la cadena outstruct que se generó en el P ASO 6. El código para invocar esta función es el siguiente: página_salida = which(‘nom bre_página_salida.html’); retstr = htmlrep(outstruct,página_salida); En la pr imera línea de este código se le esta asignando a la variable página_salida la ruta completa en la que se encuentra la página nombre_página_salida.h tml, esto se hace a través de la función which. En la segunda línea de código se le esta asignando al cadena de retstr, la cual fue iniciada en el PASO 2 el resultado de la función htmlrep la cual le asigna a la página que se encuentre asignada en el parámetro página_salida los valores de los resultados, gráficos o tablas que se encuentren en el parámetro outstruct, el cual se explico en el PASO 6.

21

3.3.3 Módulo Web C am El tercer módulo que se va a implementar en la arquitectura 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 donde 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 como se desarro lla la práctica que esta realizando. La cámara que se utilizó es una Logitech Clicksmart 310. 3.3.4 C omunicación entre m ódulos 3.3.4.1 Interfaz Hombre/Máquina con Módulo Controlador C E 150 La comunicació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 funcione, fue necesario hacer que la máquina a la cual estaba conectado el helicóptero CE 150 funcionara como un servidor. Para esto fue necesario instalar el IBM HTTP Server, el cual es de uso grat uito. El proceso de comunicación entre la página 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 comunica con la Unidad de Interfase a través de la tarjeta I/O MF614. La com unicación que hay entre el controlador y la tarjeta se hace por medio del Real Time Toolbox, el cual por medio de MATLAB envía las señales de control (estímulos DC a los motores) a la tarjeta MF614 quien posteriormente envía la señal a la unidad de interfase y esta al modelo del helicóptero CE 150. Para ver la configuració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 Hom bre/Máquina con la Módulo Web C am La comunicación que hay entre estos dos módulos se hace por medio del soft ware Windows Media Encoder. Este software permite hacer una conexión desde la página HTML con la Web Cam y transmitir lo que se esta observando en esta. El Media Encoder hace una conexión a través del puerto 1025 del computador y la dirección IP del mismo para que el usuar io en su página HTML observe en una aplicación de Windows Media Player el video que se esta transmitiendo. 3.4 Práct ica propuesta: Control PID Elevación El modelo del helicóptero CE 150 tiene la facilidad de restringir los grados de libertad del modelo al asegurar las rotaciones del mismo. Para esta práctica se opto por reducir los grados de libertad del Helicóptero y hacer todo el exper imento únicamente sobre la

22

variable de elevación. Se planteó una práctica en la cual el usuario puede realizar 3 procedimientos:

• Diseñar el tipo de estímulo que desea aplicar le al helicóptero CE 150 ya sea para caracterizar la p lanta o para controlarlo.

• Caracterizar 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 modelo. Para estas 3 herramientas 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 herramienta el usuario podrá hacer simulaciones de los estímulos que desea aplicarle al sistema ya sea para hacer una caracterización o para aplicar el control PID. Con esta herramienta el usuario podrá variar los parámetros de la señal de entrada que se ap licara al sistema. Esta herramienta es de gran utilidad puesto que si el usuar io genera en ella la entrada que va a aplicar al sistema, una vez vaya a correr el experimento ya va a estar seguro que la entrada que desea aplicarle al sistema es la correcta. La herramienta de sim ulación de estímulos no hace que corra el exper imento por lo tanto la respuesta es mas ráp ida. 3.4.1.1 Documento de ingreso de datos Este documento de ingreso de datos es una página HTML en donde se le pide al usuario los valores que debe ingresar para generar un estímulo ya sea para 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 observar los 7 campos que el usuar io debe escoger o modificar para diseñar su entrada.

23

Tipo de Estímulo: En este campo el usuar io podrá escoger entre la opción Nivel DC y

Angulo. Al elegir la opción de Nivel DC el usuario estará diseñando un estímulo que podrá aplicar al experimento de caracterización. Al escoger la opción Angulo el usuario estará diseñando un estímulo que podrá aplicar al experimento del control PID.

Tipo de Trayectoria : En este campo el usuario podrá 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 ingresar el tiempo total que

se va a demorar su experimento. Este tiempo debe ser ingresado en segundos.

Valor medio: En este campo el usuario decide cual va a ser el valor medio de la señal de

entrada. Si la señal de entrada es una constante, el valor medio será el que va a determinar el valor de la señal constante.

Amplitud: Este campo se ingresa el valor máximo que puede alcanzar la magnitud

oscilante de la trayectoria en un periodo de tiempo. Para el caso de la señal constante, este parámetro no aplica.

Periodo: En este campo el usuario podrá modificar el tiempo que tarda 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 campo el usuario podrá modificar la fase de la trayectoria que ha

ingresado. Para el caso de la señal constante, este parámetro no aplica.

La diferencia entre hacer una simulación de un estímulo de una Señal DC a un estímulo de Angulo 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 alcanza los 8 Voltios y cuyo valor mínimo es de -8 Voltios. Esta normalización es necesaria debido a que la unidad de interfase viene codificada para interpretar los valores entre -1 y 1. En el caso de que el estímulo sea un ángulo, se esta haciendo la simulación de una entrada para la práctica de control. Este ángulo tiene 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.

24

En la tabla 5 se pueden observar cuales son los límites de cada una de las características de un estímulo.

Tipo de estímulo Categoría Nivel DC Angulo

Ti po de Trayectoria

• Constante • Esca lón • Rectángu lo • Triangulo • Senoidal • Ruido

• Constante • Escalón • Rectángu lo • Triangulo • Senoidal • Ruido

Tiem po Total de Simulación (segundos)

Valor mínimo = 1 Valor máximo = 50

Valor mínimo = 1 Valor máximo = 50

Valor Medio Valor mínimo = -1 Valor máximo = 1

Valor mínimo = -3 Valor máximo = 3

Amplitud Valor mínimo = -1 Valor máximo = 1 *Es im portante verificar que la suma del valor medio y la amplitud, no excedan los límites.

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.

Periodo Valor mínimo = 0 Valor máximo = Tiempo total de simulación.

Valor mínimo = 0 Valor máximo = Tiempo total de sim ulación.

Fase Valor mínimo = -π/2 Valor máximo = π/2

Valor mínimo = -π/2 Valor máximo = π/2

Tabla 5. Límites permitidos 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 ingresando en la página HTML contenga toda la información necesaria para realizar la práctica y que ésta no sobrepase los límites de nuestro modelo. Por esto fue necesario implementar un algoritmo en el que se valida la información que se esta ingresando en la página antes de enviar la al modelo. En la figura 11 se observa el algor itmo que se planteó, en el cual se verifica que:

• Todos los campos para ingresar los datos del estímulo de entrada tengan un valor.

• El valor ingresado sea un valor numérico.

• Que el valor ingresado se encuentre entre los límites permitidos por el modelo.

25

El código Javascript generado para validar la información de las características del estímulo se encuentra en el anexo 7.2. Siguiendo con las especif icaciones del punto 3.3.1.1, en esta página HTML de ingreso de datos se incluyeron las siguientes líneas: <form action="/cgi-bin /matweb.exe" m ethod="POST" target="outpu twindow" onsubmit="return checkform (this)"> <inpu t type="hidden" nam e="mlm file" value="simulacion"> En la primera de ellas se esta invocando el archivo mat web.exe para iniciar la ap licacion en MATLAB. El comando onsubmit ="return checkform(this)" es el encargado de llamar la function de validación previo a enviar la información recolectada. En la segunda línea, se coloca el nombre del archivo .m o controlador, en este caso “simulación”, el cual está encargado de realizar la respectiva sim ulación en MATLAB y de generar el gráfico que será devuelto al usuario para que revise si la entrada que programó es la deseada. Finalmente, la página HTML de entrada de datos tiene un botón sobre el cual el usuario puede dar clic y enviar el formulario diligenciado apropiadamente a la aplicación en MATLAB para que esta corra y genere los resultados esperados. El resultado final de esta página (Estímulos.html) se puede ver en la figura 12.

26

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

27

Figura 12. Página HTML de ingreso de datos para la simulació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 ingreso de datos es posible empezar a trabajar con ellos en la herramienta MATLAB. Como se especifico en el formato general del controlador o archivo .m en el punto 3.3.2, los pasos para el diseño de este archivo dieron como resultado el siguiente código: PASO 1 function PageStr ing = simulacion(Input Set) PASO 2 PageString = char( ''); PASO 3 cd(Input Set.mldir); PASO 4 % parametros de tiem po Tt= str2double(Input Set.Tt); % Tiem po Total

28

% parametros de la trayectoria Xo1=str2double(InputSet.Xo1) ; % valor m edio Xm1=str2double(Input Set.Xm1); % amplitud to1=str2double(Input Set.to1); % periodo phi1=str2double(InputSet.phi1); % fase tray=InputSet.Trayectoria; % tipo de trayectoria estímulo=Input Set.estímulo; % tipo de estímulo PASO 5 El primer paso para poder generar el resultado de la simulación deseada por el usuario, es definir el tipo de entrada que se va a ap licar sobre el sistema. Como este algoritmo se va a repetir para todos las posibilidades que ofrece esta práctica (caracterización, práctica de Control), se propuso el algoritmo general que se encuentra en la f igura 12. En este algoritmo se define que tipo de trayectoria desea el usuario, y una vez se tenga esta información, dependiendo 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 tiempo de muestreo fuera 0.1 segundos, lo cual para una prueba de 25 segundos de duración, nos genera un vector de 250 puntos. Para la práctica de caracterización y control PID esta tasa de muestreo la def ine el usuario. Para ver el código en el que se define el tipo de trayectoria, ver anexo 7.3. Después de obtener el vector deseado con todas las características que el usuario ingresa 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, ver anexo 7.4 PASO 6 En este archivo .m solo estamos generando un gráfico que va a ser mostrado al usuario final. Del mismo modo estamos tomando el valor del tipo de estímulo que se va a realizar para comunicarle al usuar io que tipo de simulación se llevo a cabo Para poder enviar el gráfico generado, y el tipo de estímulo es necesar io vincularlo en una estructura en la que se pueda enviar al página 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); wsprintjpeg(Fig, salida.GraphFileNam e); salida.GraphFileName = sprintf('/icons/estímulo% s.jpeg', InputSet.m lid); En este caso la estruct ura que se va a enviar desde el archivo .m (simulacion) hacia la página de salida va a ser s. El nombre del archivo es estímulo.jpeg el cual se va a guardar en la carpeta raíz del servidor. Aparte de generar el resultado gráfico de la simulación, también se genera un archivo en formato Excel, el cual el usuario podrá bajar desde la página de salida de datos para hacer los respectivos análisis de ser necesario.

29

Figura 12. Algoritmo para definir la Trayectoria PASO 7 Se pasa a la página de salida (estímulos2.html) el gráfico generado por el archivo .m previamente. Este es el código para hacer este procedimiento: templatefile = which( 'estímulos2.html'); %en este com ando de identifica la ruta de

la página Estímulos2.htm l PageString = htmlrep(s , templatefile); % con este com ando se enví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 llama al archivo .m (simulación) .En esta página, se van a mostrar el gráfico generado durante la simulación y se le indicará al usuario que tipo de estímulo fue el que generó. El código en donde se referencia la variable de los estímulos y el gráfico es el siguiente: <p> El resultado de su simulación de $valor$ fue exitosa.</p> <img border=0 src="$GraphFileName$">

30

Si miramos el código del PASO 6 del punto 3.4.1.2 podemos ver que la estructura de la variable salida, que es la que reemplaza los valores en la página estímulos2.html tiene la var iable valor, y el gráfico GraphFileName. El código de la página HTML de salida se puede ver en el anexo 7.5; esta estruct ura será utilizada para las páginas de salida de la caracterizació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 manera:

Figura 13. Página HTML para salida de datos de simulación de estímulos 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 puede ap licar al sistema oscila entre -1 y 1; éste valor está normalizado y equivale a un voltaje de +/- 8 Voltios. El signo de la señal determina el sentido en el que giran las hélices. El est udiante ingresara los valores que se piden en las características generales en la página HTML de ingreso de datos y se establecerá una conexión mediante una aplicación de Windows Media Player con la Web Cam a través de la cual podrá observar como transcurre la caracterización en v ivo. Una vez el experimento concluya,

31

el estudiante recibirá una gráfica en la que podrá observar las mediciones tomadas 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 los resultados, podrá bajarlos en un formato .xls para realizar sus respectivos cálculos.

Figura 13. Modelo del sistema de Caracterizació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 diferencias entre las dos páginas, son:

• Esta página no tiene el parámetro de Tipo de Estímulo pero tiene el parámetro de Tiempo de M uestreo

• En esta página esta la aplicación de Windows Media Player para observar lo

que esta sucediendo a través de la Web Cam.

• El nombre del arch ivo .m que va a generar la aplicación en MATLAB se llama es caracterizacion.m

El algoritmo utilizado para validar los datos que se ingresaron es el mismo planteado en la figura 11 teniendo en cuenta las diferencias en los parámetros. Debido a que en este experimento el usuar io puede ingresar el valor de la tasa de muestreo los límites para la variable de Tasa de muestreo son los siguientes: Trayectoria de Caracterización Tasa de muestreo Valor mínimo = 0.01

Valor máximo = 0.5

Tabla 6. Límites de Tasa de muestreo Estos rangos se establecieron debido a la limitación del soft ware y la velocidad de la máquina en donde se corría el proceso. Cualquier valor por fuera de este rango afectaba el desarrollo del experimento.

32

La página de ingreso de datos para la práctica de caracterización es la siguiente:

Figura 14. Página HTML de ingreso de datos para la caracterización de la planta Se puede observar en la figura 14 en la parte central izquierda, los campos que debe llenar el usuario para generar el estímulo que se le va a aplicar a la planta. Se observa claramente que son iguales a los que se muestran en la figura 10 con las diferencias pequeñas que se mencionaron anteriormente. En la parte infer ior izquierda, esta la aplicación de Windows Media Placer por medio de la cual el usuar io podrá lo que esta sucediendo con el modelo real del helicóptero en tiempo real. Debajo de la aplicación del Windows Media Placer se encuentra el botón de “ Submit” por medio del cual el usuar io dará inicio a su práctica siempre y cuando los valores que se hayan ingresado en Características Generales estén dentro de los límites de la práctica.

33

3.4.2.2 Archivo .m: Controlador 3.4.2.2.1 Definición de contadores [10] Para poder establecer una comunicació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 herramienta, la comunicación es sincrón ica y los procesos que se realizan a través de esta son por medio de los contadores. El contador no solo es un dispositivo que provee tiempo, sino que también se utiliza como un objeto para realizar acciones en tiempo real. Un contador es definido con el comando rtdef el cual tiene las siguientes conf iguraciones: rtdef (nombre, ‘tipo’,periodo, canal, numerador, denominador) rtdef(‘var_hist’,la rgo,ancho) Estas son las dos formas en que se van a usar los contadores para controlar el modelo. En la pr imera configuración se define un contador nombre, cuyo tipo puede ser ‘in’ o ‘out’. Si el tipo es ‘in’ el contador estará encargado de leer información, mientras que si es ‘ou t’ solo enviara información. El periodo determina cada cuanto se va a enviar o recibir información en este contador. El canal es equivalente a los canales de la tarjeta MF614 a través de los 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 transferencia, en cuyo caso el tipo puede ser ‘tfin’, ‘ tfout’,’m vtfin’,’mvtfout’ (función de transferencia de entrada, función de transferencia de salida, función de transferencia multivariable de entrada, función de transferencia de salida multivar iable). En la segunda conf iguración, el contador se def ine como una variable h istórica con nombre var_hist. Con esta configuración, es posible asignarle a un contador los valores de una variable para que estos sean interpretados como comandos de ingreso para otros contadores y realizar una acción en tiempo real, o simplemente se puede utilizar como una variable en donde se almacenan los datos que se lean del mundo exterior. Los parámetros de ancho y largo, determina 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 los valores que estos tienen se hace a través de los comandos rtwr y rtrd. Por medio de estos comandos es posible escr ibir valores predeterminados al contador, ya sea asignándole el valor de una variable en el programa o hasta un vector completo. Cuando se utiliza el comando rt wr, los parámetros que utilizan esta función son el nombre del contador o variable histórica al cual se desea escribir algo, y el valor que se va a enviar. Cuando se usa el comando rtrd, es necesario pasar como parámetro el nombre del contador o variable histórica del cual se desea leer información. Otra facilidad que ofrecen los contadores es que pueden comunicarse entre ellos mismos, es decir, si un contador es de tipo ‘out’, el valor que este escribe puede ser la entrada de un contador de tipo ‘in’. Como todos los contadores funcionan sincrónicamente, es posible realizar esta conexión sin ningún problema; no obstante, es

34

importante tener en cuenta que los periodos de muestreo y los tamaños de estos deben coincidir. 3.4.2.2.3 Módulo de tiem po real Debido a que este archivo .m tiene características similares al archivo .m de simulación vamos a hacer énfasis en el PASO 5, que es donde se establecerá la comunicación con la interfase del helicóptero CE 150. El procedimiento realizado para la generación del vector de la trayectoria es el mismo que se utilizó en el archivo de simulación y es el que esta descr ito en la f igura 12. Una vez se obtiene este vector, es necesario 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 tamaño al generado por el algoritmo 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 canal 6 de la tarjeta MF614). La lectura del ángulo de elevación que nos proveen los contadores incrementales ubicados en el helicóptero, se envía desde la un idad de interfase a la tarjeta MF614 por medio del canal 3. De este modo es necesario crear contador 3 con características de una variable histórica, en el cual se va a almacenar cada medida que sea enviada por la unidad de interfase. Todos estos contadores deben tener el mismo per iodo de muestreo y es aquel que determine el usuario en la página de ingreso de datos.

35

Figura 15. Algoritmo del módulo de tiempo real de caracterización.

Teniendo la asignación de los contadores completa, es posible correr el experimento iniciando los contadores simultáneamente. Los resultados del experimento 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 muestra el ángulo de elevación del helicóptero en el transcurso del experimento. Este gráfico se le muestra al usuario en la página HTML de los resultados y por lo tanto se debe realizar el mismo procedimiento que se h izo en el archivo .m de simulación en los P ASOS 6 y 7 en donde se genera una estructura que se pueda enviar a la página HTML de salida (caracterizacion2.html). El código del archivo .m de caracterización esta en el anexo 7.6. 3.4.2.2.4 Documento de salida de datos La estructura de este documento es igual al documento de salida de la simulación de estímulos. El usuario podrá ver en la página los resultados del exper imento de

36

caracterización que serán 2 gráficas en las que se m uestran el nivel DC aplicado y el ángulo resultante a este estímulo. En la figura 16 se muestra el resultado de la página que m uestra los resultados del exper imento de caracterización.

Figura 16. Página HTML para salida de datos de la caracterización

3.4.3 C ontrol PID 3.4.3.1 Documento de ingreso de datos En este documento de ingreso de datos, se utilizan parámetros del documento de ingreso de datos de la práctica de caracterización y además los tres valores del controlador PID de primer grado (Kp, Ti y Td). El usuar io podrá hacer el diseño de su controlador basado en los resultados que se obtiene en el experimento de caracterización utilizando cualquier método de sintonización que se ven en un curso de control. Una vez el usuario tenga los valores del controlador PID podrá ingresarlos en la página, ejecutar la práctica y observar por medio de la Web Cam como se desarrolla su experimento. El sistema para la práctica del control PID que se va a implementar tiene la siguiente estructura:

37

Figura 17. Modelo del sistema para la práctica del control PID El proceso de validación de ingreso de datos es el mismo que se utilizó en las páginas mencionadas anteriormente. Para los valores de los parámetros del controlador PID se verifica que haya un valor en la casilla de ingreso, y que éste sea un valor numérico. La página de ingreso de datos de la práctica de control PID de elevación es la siguiente:

Figura 18. Página de ingreso de datos de la práctica de controlador PID de elevación

38

El archivo .m que se invoca en documento de ingreso de datos de la práctica PID de elevación se llama controlPID.m . 3.4.3.2 Archivo .m: Controlador El controlador de la práctica de control PID para elevación del helicóptero CE 150 tiene un formato muy parecido al que se utilizó en la práctica de caracterización. Las variables que se tratan en este archivo son las mismas utilizadas en caracterizacion.m y además se tienen en cuenta los parámetros del controlador PID. Los parámetros del controlador PID son utilizados para calcular un controlador en tiempo continuo. Debido a que el módulo de tiempo real es sincrónico y los contadores funcionan con un periodo de muestreo determinado por el usuario, es necesario convertir el polinomio continuo a uno discreto. Para esto se utilizó una función (anexo 7.7) que hace el siguiente cambio:

( ))(min

)()(11zadorDeno

zNumeradorzUsTsT

KsU DI

P =⇒⎟⎟⎠

⎞⎜⎜⎝

⎛++=

Una vez se obtiene la función de transferencia del controlador PID discreto es posible generar el módulo de tiempo real que controlará el helicóptero. En la figura 19 se observa el algoritmo planteado para enviar las señales de control al helicóptero CE 150 teniendo en cuenta el controlador PID diseñado y para ver el código del archivo .m refiérase al anexo 7.8.

39

Figura 19. Algoritmo de módulo de tiempo real para el controlador PID

3.4.3.3 Documento de salida de datos El archivo de salida de datos de la práctica del controlador PID tiene la misma estructura que los archivos de salida de las prácticas mencionadas anteriormente. En este caso, en los resultados se muestra el ángulo de entrada y el ángulo de salida en una misma grafica para efectos de análisis. En otra grafica se m uestra el voltaje del motor principal.

40

Figura 20. Página HTML para salida de datos de la práctica de control 3.5 Herramienta de análisis de resultados Las prácticas de caracterización y de control PID ofrecen al est udiante la opción de ver como se desarro lla la práctica por medio de la Web Cam y un gráfico con los resultados de las mediciones tomadas durante el experimento. Aunque la transmisión del video en tiempo real le ofrece al estudiante la posibilidad de sentirse “físicamente” en el laboratorio no había una un ión en tiempo real del video con los resultados. Por esto se planteó la opción de desarro llar una herramienta que uniera el video que se registra en la práctica con los resultados. La herramienta que se desarrollo para lograr este objetivo se h izo con la ap licación Flash de Macromedia. Lo que hace esta herramienta es tomar la grabación del video de la práctica que se ejecuto y lo une con la grafica de resultados por medio de un cursor que esta sincron izado entre las dos acciones. En la figura 21 se muestra una secuencia de un exper imento en la herramienta desarrollada. En esta secuencia se muestra el desarrollo de una caracterización en donde se le ingresa una entrada escalón a los 10

41

segundos. Para mayor descr ipción de la entrada y los resultados de este experimento en particular se puede refer ir a la figura 16. Esta herramienta no se desarrollo en su totalidad en este proyecto de grado. Tan so lo se hizo la prueba con un experimento en particular. Para poder automatizar esta opción dentro del módulo de control del laboratorio a distancia de la ULA es necesario desarrollar otro proceso que involucra la creación de soft ware mas sofisticado. El primer paso que hay que desarrollar es la captura del video que se trasmite mientras se ejecuta la práctica. Es de vital importancia que el v ideo que se grabe para retransmitir en la herramienta en flash tenga la misma duración en tiempo que el gráfico de los resultados. Para poder hacer esto se hizo un análisis de las opciones que se pueden tener para completar dicho objetivo.

42

Figura 21. Secuencia de la herramienta en Flash

43

3.5.1 Opciones de captura de video 3.5.1.1 Windows Media 9 Series [11] En esta opción el administrador puede programar varias opciones del Windows Media Encoder, soft ware con el cual estamos transmitiendo la señal de video, para que el usuario desde la página HTML en la cual se ingresan los datos de las respectivas prácticas de inicio al proceso de codificación y almacenamiento del v ideo una vez se inicie la práctica. Para poder lograr esto es necesario utilizar interfaces como IWMEncAgentLocator, IWMEncoderAgent y IW MEncoderNamesCollection, en donde se deben programar rutinas para que el cliente en este caso se el encargado de iniciar el proceso de monitoreo y proceso de codificación. Estas rutinas deben utilizar las funciones de DCOM Conf ig para crear el acceso, asignar los niveles de segur idad necesarios al programa Encoder y al Windows Media Encoder Agent, para se empiece a grabar una vez se de inicio a la práctica. Estas rutinas se pueden programar en C, Visual basic .NET o en C++ 7.0. 3.5.1.2 C amstudio [12] Esta opción es un programa que se utiliza para registrar la actividad de la pantalla del computador en un archivo .avi. Para el caso especifico de grabar el video de la práctica del helicóptero, se debe conf igurar la herramienta para que grabe lo que esta sucediendo en el área en donde se encuentra el Windows Encoder, ya sea en el computador del usuario o en el servidor. Para esto, es necesario programar una aplicación que se encargue de ejecutar este programa con todos los parámetros predeterminado una vez se le de inicio a la práctica desde la página HTML y que grabe por el tiempo que dura el experimento. Esta aplicación se puede programar en los mismos lenguajes mencionados en 3.5.1.1.

3.5.1.3 Webcam Watchdog [13] Este soft ware, cuyo costo es de 50 dólares, tiene como propósito principal realizar labores de seguridad, pero en las aplicaciones que tiene cubren todas las necesidades de este proyecto. Este soft ware puede reemplazar el Windows Encoder puesto que tiene la funcionalidad de trabajar como un codificador con capacidad de env iar la información que registra el video que transmite una Web Cam conectada en un puerto USB a cualquier dirección IP que se le especifique. Además de esto tiene la opción que empieza a grabar una vez detecta movimiento en un rango que se le especifica dentro de los parámetros de configuración. Del mismo modo es posible configurar que tanto tiempo se desea grabar y la ruta a donde se desea guardar el video. 3.5.1.4 Recomendaciones Las 3 opciones que se p lantearon anteriormente para grabar el video de la práctica cumplen con las necesidades del proyecto; sin embargo, para implementar las primeras 2 opciones se presentan los siguientes inconvenientes:

44

• Se debe tener un buen conocimiento de los lenguajes de programación mencionados.

• Como las ap licaciones correrían a en el momento en el que se envía la señal de

inicio de práctica, es necesario tener en cuenta los retardos que se generan en la transmisión del video, los cuales no siempre son constantes y podr ía causar diferencias entre el tiempo del v ideo y la duración de la práctica.

• Se debe tener en cuenta que al iniciar la práctica desde la página HTML se

ejecutaría la aplicación de MATLAB y secuencialmente la aplicación de grabar el video, o viceversa, lo que puede causar retardos y diferencias entre el tiempo del video y la duración de la práctica.

La tercera alternativa es considerada la mejor opción para cumplir con las necesidades del proyecto. Este soft ware nos asegura que la grabación del video empezara en el momento exacto en el que inicia el experimento y finalizara simultáneamente. Además, es posible transmitir el video a la página web donde esta conectado el usuario en tiempo real. El costo de adquirir la licencia de este soft ware es relativamente bajo comparado con los benef icios que trae. Una vez que se tenga establecido el método para grabar el video el siguiente paso a desarrollar es relativamente sencillo. Se debe automatizar el proceso de la herramienta Flash para generar la unión entre el video y el gráfico resultante. Este paso es sencillo puesto que la herramienta Flash lo que hace es reproducir un video y una grafica que se encuentran en una ruta especif ica. Lo único que hay que hacer para que esta funcione cada vez que se genera una práctica, es guardar tanto el video como el gráfico en la ruta en donde esta apuntando la herramienta Flash. 4 Conclusiones En el desarrollo de este proyecto se logró cumplir con los objetivos principales planteados. Se estableció una conexión remota a través de Internet con el Helicóptero CE 150, por medio de la cual es posible conf igurar señales de control o caracterización con las cuales se pueden realizar prácticas académicas en el área de control con dicho modelo. Para esto se diseño y desarrollo una interfaz amigable para el usuar io en la cual puede ingresar fácilmente los datos requeridos para desarrollar los respectivos experimentos. De igual forma se diseño una estruct ura básica del módulo del controlador el cual es encargado de interpretar las señales que envía el usuario a través de la interfaz visual, procesarlas y env iárselas como señales de control al modelo del Helicóptero CE 150. Cuando se inició el diseño de los módulos se t uvo en cuenta que se estaba manejando un instrumento costoso ; por esto, dentro del diseño general se tuvo en cuenta las restricciones del sistema y se planteó un algoritmo que valida los datos que van a ser ingresados al sistema para así proteger el Helicóptero CE 150 y utilizar lo de la manera mas eficiente posible.

45

Este módulo del laboratorio a distancia de la Universidad de los Andes, permite que tanto estudiantes como profesores interesados en el área de control puedan realizar una práctica experimental desde un sitio remoto a cualquier hora del día. A la vez, mientras transcurre el experimento ellos son capaces de observar en vivo como se esta desarrollando su experimento por medio de una Web Cam, recibir sus resultados en una grafica y en un archivo, y posteriormente tener la oportunidad de comparar estos resultados con el video grabado. Todas estas características mencionadas hacen que este módulo de control del laboratorio a distancia de la Universidad de los Andes permita que un estudiante se aproxime a la realidad del control a través de esta experiencia real. 5 Perspectivas Con el módulo de control: Helicóptero CE 150, el laboratorio a distancia de la Universidad de los Andes poco a poco va creciendo. Este proyecto del laboratorio aun tiene muchas cosas por desarrollar y por mejorar, entre las cuales se encuentra el módulo de control. En este proyecto de grado solo se trabajo con un grado de libertad del Helicóptero CE 150 (Angulo de Elevación), y se diseño una práctica utilizando un controlador PID de primer grado. Para el futuro estas son algunas cosas que pueden desarrollarse en este módulo y complementar lo que se ha hecho hasta el momento en el laboratorio a distancia.

• Complementar el trabajo iniciado en este proyecto de grado para el proceso de grabar el video durante el periodo que dura el experimento y posteriormente vincular lo a la herramienta desarrollada en la que se unen los resultados gráficos con los v isuales.

• Realizar el mismo experimento de controlador PID que se hizo sobre el motor de

Elevación en este proyecto de grado al motor de azimut. Para desarrollar esta práctica, es necesario poder caracterizar el modelo y aplicar un controlador al motor de azimut siguiendo las mismas pautas desarro lladas en este trabajo.

• Desarrollar prácticas más complejas y su procedimiento de apoyo.

• Ofrecer prácticas con otros controladores que sean útiles para el desarrollo

académico del estudiante en el área de control. • Poder aplicar perturbaciones externas al modelo del Helicóptero CE 150. Poder

modificar el centro de gravedad del modelo durante la práctica. Poder definir estímulos compuestos, sumar valores al set point o a la variable medida.

46

• Poder diseñar controladores a través de la herramienta Simulink de MATLAB y correrlas con la herramienta desarrollada.

• Desarrollar un sistema que una todas las prácticas del laboratorio a distancia que

se han desarrollado hasta el momento. Este sistema debe manejar el acceso de los diferentes usuarios, los t urnos y las bases de datos en donde se podrá almacenar toda la información obtenida por las distintas prácticas y así poder tener información histórica de todos los procesos realizados en el laboratorio. Esta herramienta debe permitir que un profesor ingrese y observe los resultados obtenidos por sus estudiantes durante la práctica y verificar el procedimiento que se realizo.

47

6 BIBLIOGRAFÍA [1] E. Vanegas, Proyecto de grado, “Aplicación de la tele instrumentación para el desarrollo de labora torios a distancia y manejo de instrum entos”,2004. [2] L. Ardila, Proyecto de grado, “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ám etros e interfaz para el usuario”, 2004. [3] L. Ardila, Proyecto Especial, “Estudio de la factib ilidad para la implem entación de un labora torio educaciona l a distancia vía Internet en el departam ento de Ingeniería Eléctrica y Electrónica de la Universidad de los Andes”, Agosto 12 de 2004 [4] J. A. del Alamo et al. “The MIT Microelectronics WebLab: a Web- Enabled Remote Laboratory for Microelectronic Device Characterization”. In NL 2002. See http://icampus.mit.edu/ilabs/ [5] J. A. del Alamo et al.”An Online Microelectronics Device Characterization Laboratory with a Circuit- like User Interface” ICEE 2003. [6] J. A. del Alamo et al. “Educational Experiments with an Online Microelectronics Characteriza tion Labora tory” ICEE 2002. [7] J. Gilliot et al. “A Distant Reality Environm ent For Contro l Teaching”. Laboratoire COSI, Groupe ESIEE. France. [8] HUM USOFT, “CE 150 Helicopter Model, User´s Manual”,1992. See http://www.humusoft.cz/models/ce150.htm [9] http://www.mathworks.com/products/webserver/ [10] HUMUSOFT, “Real time Toolbox, for use with MATLAB, User´s Manual”, 1992 [11]http://msdn.microsoft.com/library/default.asp?url=/library/enus/wmencode/htm/remoteadministration.asp [12]http://www.brothersoft.com/Multimedia_Graphics_Screen_Capture_CamStudio_3944.html [13]http://www.webcamsoft.com/en/watchdog.html [14]http://chem.engr.utc.edu/

48

7 ANEXOS 7.1 Información técnica del cableado de la tarjeta MF614

49

50

7.2 C ódigo Javascript de Validación function chec kf orm(form) { { if(form.Tt.value == "") { alert( "Por favor Inserte un numero en Tiem po total") ; form.Tt.foc us; return false;

51

} if(!range(form.Tt.value,1,50)) {

alert( "Por favor Inserte un numero en Tiem po tota l entre 1 y 50") ; form.Tt.foc us; return false; } if(form.Xo1.value == "") { alert( "Por favor Inserte un numero de Valor Me dio") ; form.Xo1.f ocus; return false; } if(!range(form.Xo1.va lue,-1,1)) { alert( "Por favor Inserte un numero en Valor me dio entre - 1 y 1"); form.Xo1.f ocus; return false; } if(form.Xm1.value == "") { alert( "Por favor Inserte un numero en Amplitud"); form.Xm 1.foc us; return false; } if(!range((f orm.Xm1.value+f orm.Xo1.va lue),- 1,1)) {

alert("Con esta Amplitud y el Valor medio, la se ñal exce de los lím ites de 1 y -1") form.Xm 1.foc us; return false; } if(!range(form.Xm1.value,- 1,1)) { alert( "Por favor Inserte un numero en Amplitud entre -1 y 1") ; form.Xm 1.foc us; return false; } if(form.to1.va lue == "") { alert( "Por favor Inserte un numero en Per iodo") ; form.to1.focus; return false; } if(!range(form.to1.va lue ,0,f orm.Tt.value)) {

alert( "Por favor Inserte un numero en Per iodo menor al Tiempo tota l y mayor a 0"); form.to1.focus; return false; } if(form.phi1.value == "") { alert( "Por favor Inserte un numero en Fa se "); form.phi1.foc us; return false; }

52

if(!range(form.phi1.value,0,form .Tt.va lue)) {

alert( "Por favor Inserte un numero en Fa se me nor pi/2 y mayor a –pi/2") ; form.phi1.foc us; return false; } return tr ue; } } function ra nge( input, lo, hi) { var num = parseI nt(input,10) ; if(num < lo || num > hi || isNaN(num)) { return false; } return tr ue; } 7.3 C ódigo para definir vector de Trayectoria TT = floor( Tt/Ts); % con esto se calc ula e l numero de muestras que se v an a tomar %en e ste punto se de fine c ual es la trayec toria que se va a emplear if strcmp(tray,'Consta nte') %constante w1= zeros(TT,1) ; elseif strcmp( tray,'Esca lon') %Escalon w1=(1:TT)'>(to1/Ts) ; elseif strcmp( tray,'Rec tangulo') %rectangulo w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); w1 = sign( w1) ; elseif strcmp( tray,'Tria ngulo') %triangulo w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); w1 = a sin(w1)/( pi/2) ; elseif strcmp( tray,'Se no') %seno w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); elseif strcmp( tray,'Ruido') % Ruido w1=c umpr od( 1-2*(rand(TT,1)<2*Ts/to1(1))); end w1=w1*Xm 1+Xo1; % Ac a se multiplica por la amplitud y se de l suma e l valor medio

53

7.4 C ódigo para generar gráfico de simulación de Estímulos Fig = figure( gcf); gnext= 0; gstep=max([TT/50,0.3/Ts,1]); hold off clf subplot(111) plot(Ts*(1:TT),w1,'-b') axis([ 0 TT*Ts -1 1]) title('Estímulo de e ntra da') grid xlabel(' tiempo [s]') ylabel('Voltaje DC') hold on; drawnow; 7.5 C ódigo HTML de la página de salida de Estímulos. <html> <body bgc olor= "#FFFFFF"> <hr> <p><font size ="5">El resultado de su simulación de $va lor$ f ue exitosa .</f ont></p> <hr> <p align="center"><f ont size="5">Esta es la señal que podrá a plicar al modelo</f ont></p> <p>&nbsp;< /p> <p align="center"> <img border=0 src="$GraphFileName $"> </p> <p align="lef t"> &nbsp;</p> <p align="center"> <font size= "4">Para bajar el arc hivo de los resultados en f ormato Excel haga clic k aquí: < /font> <input type= "button" name ="Submit1" va lue= "Bajar archivo" onclick= "docume nt.location.href ='/icons/da tos_gráfic o.xls' ; "><p> </body> </html> 7.6 C ódigo de archivo .m de caracterización function Pa ge Str ing = carac t(InputSet, OutFile) %parametr os de tiempo Ts= str 2double(I nputSe t.Ts) ; Tt= str 2double(I nputSe t.Tt) ; %parametr os de la trayector ia Xo1=str2double(InputSet.Xo1); Xm1= str 2double(I nputSe t.Xm1); to1=str2double(InputSet. to1); phi1= str 2double(I nputSet.phi1); tray=InputSe t.Trayectoria ; %Varia ble s que determ ina n el filtro de entrada (off set) ircscale =1024; el_off set=-0.25; % offse t ele v

54

Fts=0.1; Fnum= 9.53674e- 007; Fden= 1; Fnum = [1/irc scale]; % filtr o de entrada Fden = [1] ; Fts = 0.1; u10 = 0.50; % offset motor principal u20 = - 0.18; clc; if ~(exist('fname')==1) % rese t de parame tros fname = ''; end if prod(f name)==prod('he 1demo'); % 1- init data , -1 -resume choice=-1; else choice=1; end rtload('mf614',65535,[0 1 1 1 1 1 1 1 1 250000 250000 250000 250000 3 3 3 4]) ; % he licopter driver rtout(5,20000); %PWM frequenc ies rtout(7,20000); rtout(8,0); i=TT; TT = floor( Tt/Ts); % nr. muestra s %if (i~=TT) w1=Xo1+ zeros( TT,1); z= zeros(TT,4) ; if strcmp(tray,'Consta nte') % const w1= zeros(TT,1) ; elseif strcmp( tray,'Esca lon') % step w1=(1:TT)'>(to1/Ts) ; elseif strcmp( tray,'Rec tangulo') %rectangle w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); w1 = sign( w1) ; elseif strcmp( tray,'Tria ngulo') % tr iangulo w1 = sin((1:TT)'*(2*pi*Ts/to1)+ phi1); w1 = a sin(w1)/( pi/2) ; elseif strcmp( tray,'Se no') % se no w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); end w1=w1*Xm 1+Xo1; % se suma el offse t, y la amplitud de la se nal c=w1; rtclear; rtdef(19,'out',0.1,[11 12]); % habilita los timer s para los motores rtwr(19,[ 1 0]) ;

55

rtdef('w1',TT,1) ; % vec tor de nivel DC desea do rtwr('w1',c); rtdef('u1',1,1); % offset motor principal rtwr('u1',u10); rtdef('el_off',1,1) ; % FOCET de elevación rtwr('el_off',el_off set) ; rtdef(1,'tfin',Ts,[.. . 211 .. . % ],Cnum w1,Cdenw1); ],1,1) ; rtlink( 1,'w1'); rtdef(3,'mvtf in',Fts,[... % elevation 9 .. . % y(elev) 253 .. . % el_offset ],[Fnum ;1],Fden) ; rtlink( 3,'el_off',253) rtdef(5,'tfin',Ts,[.. . % elev-filter 221 .. . % y(elev) ],1,1); rtlink( 5,3) rtdef(7,'mvtf in',Ts,[... % set point de elevac ión 231 .. . % yf(elev) 233 .. . % wf(elev) 235 .. . % offs(ele v) ],[1;1;1],1) ; rtlink( 7,5,231) rtlink( 7,1,233) rtlink( 7,'u1',235) rtdef(9,'out',Ts,[.. . %Controlador logico de se nal DC 251 .. . % u(elev) ]) rtlink( 9,7,251) rtdef(10,'out',Ts,[ ... % Contorla dor de la se nal DC e nviada al m otor 6 .. . % u(elev) ]); %rtlink(10,9) rtlink( 10,1) rtdef(15,'in',Ts,[.. . 205 .. . % y(elev) 207]);.. . % u(elev) rtlink( 15,3,[ 205]) rtlink( 15,9,[ 207]) rtdef(' z',TT,2,1); % vector donde se graba la s lec turas de los %sensore s rtlink(' z',15) rtstart([7 9 10 19]) % inic io d em otores gnext= 0; % conta dore s de los grafic os gstep=max([TT/50,0.3/Ts,1]); hold off clf

56

figure( gcf) subplot(111) plot(Ts*(1:TT),c,'-b'); %axis([0 TT*Ts - 0.25 0.25]) axis([ 0 TT*Ts -1 1]) title('He lic opter elevation') grid xlabel(' time [s]') ylabel('angle [-]') hold on t = Ts*(2+2); rtwr(7,'time', t) rtwr(7,'t',0) t=1; t_= 0; t__=0; rtstart([1 3 5]) % se inician los se nsores while (r trd( 7,'t')==0) % calibración de se nsores y1__=rtrd(3,'y '); end rtflush % inic ia la gra bacion de los sensores rtstart(15) while t<TT if t>=gnext y1=r trd( 3,'y'); plot([t;t__] *Ts,[y1;y1__],'-g','erasemode','none') drawnow y1__=y1; t__=t; gnext=t+gste p; end t_=t; while t== t_ t=(rtr d(15,'t')); end % ciclo para e l siguie nte pa so de medic ión end % for z = rtr d('z'); rtunlink([ 10 ]) %Parar motores rtwr(10,'y',[0]); while (r trd( 15,' t') < t+ 2);e nd rtclear % Rese t de Timers hold off % borrar graf icos a ntiguos clg % Graficos de los resultados Fig = figure('visible','off'); hold off

57

clf figure( gcf) subplot(211) % Angulo de ele vacion angulo= z(:,1); ejeymax=max(angulo); ejeymin=min(angulo); ejeymax=ejeymax+(0.35-ejeymax)/2; ejeymin=ejeymin+(-0.3+ejeymin) /10; plot((1:TT)*Ts,w1,'-w',... (1:TT)*Ts,angulo,'-g') xlabel('Tiempo [s]') axis([ 0 TT*Ts ejeymin ejeymax]) text(0,1,'Elevac ion','units','norma lize d','hor izonta lalignment','left','vertica lalignme nt','bottom','fontweight','bold') subplot(212) %Motor Pr inc ipa l ejeymax1=max(c); ejeymin1=min(c); ejeymax1=ejeymax1+(3.5-ejeymax1) /10; ejeymin1=ejeymin1+(- 3+ejeymin1) /10; plot((1:TT)*Ts,c,'-r') grid axis([ 0 TT*Ts ejeymin1 ejeymax1]) % Voltaje de l motor pr inc ipa l axis(a xis) text(0,1,'Nive l DC motor principa l','units','norma lize d','hor izonta lalignment','left','ver tica lalignment','bottom','fontweight','bold') k=[0.01 1.00]; % Explicac ión de los c olores de l graf ico l=[0 0.05] ; [k,l]=sc2dc( k,l); v = axis; axpos = get(gca,'position'); k = v(1) + ( k-axpos( 1))*( v(2)- v(1)) /axpos(3); l = v(3) + (l-a xpos(2))*(v(4)-v(3))/axpos(4) ; k0= k(1) ; dk= diff( k); l0= l(1) ; dl= diff( l); line(k([1 2 2 1 1]) ,l([ 1 1 2 2 1]),'line style','-','color',[1 1 1] ,'clipping','off') x= k0+dk/3*(( 0.7:2))' ; y=l0+dl/2* [ 1 1]'; text(x,y,['Nivel DC: ';' Angulo Sa lida '],'horizontalalignme nt','right') x=[x x+dk*0.07] ; y=[y y]; line(x(1,:),y(1,:),'c lipping','off','color',[1 0 0]) line(x(2,:),y(2,:),'c lipping','off','color',[0 1 0]) subplot; axis; hold on; drawnow; % Ge neracion del archivo exce l para entregar al usuario% tiempo= Ts*(1:TT); datos=a ngulo'; DC=w1'; valor=[tiempo;datos;DC] ; fid = fopen('datos_caract.xls','w') ; fprintf(fid,'Tiempo \t Elevacion \t Nive l DC \n');

58

fprintf(fid,'%f %f %f \n',valor); status = fclose(fid); %creacion de la variable s con el graf ico de salida% s.GraphFile Name = spr intf('hedemo%s.jpe g', InputSet.mlid) ; wsprintjpeg( Fig, s.Gra phFile Name); s.GraphFile Name = spr intf('/ic ons/hedem o%s.jpeg', InputSet.mlid) ; close all; templa tefile = which('caracterizac ion2.htm l'); Page String = htmlre p(s , templa tefile); 7.7 C ódigo de función que convierte controlador continuo a polinomio discreto function [Cnumy,Cde ny,Cnumw,Cdenw]= pid2z(Ts,Kp,Ki,Kd,Tf,tm p) Tf=tmp; end Cnumw = Kp; % Com ponente P Cnumy = Kp; Cdenw = 1; Cdeny = 1; Cnumw=Cnumw * [ 1 -1] + ... % Com ponente I [1 0]*Ki*Ts; Cnumy= Cnumy * [1 -1] + .. . [1 0]*Ki*Ts; Cdeny= Cde ny * [ 1,-1] ; Cdenw= Cde nw * [ 1,-1] ; if Tf k=-e xp(-Ts/Tf) ; % Com ponente D else k= 0; end l = l*( 1+k) ; Cnumy = c onv( Cnumy,m) + .. . conv( Cdeny, l); Cdeny = conv(Cde ny,m);

7.8 C ódigo de archivo .m de control PID function Pa ge Str ing = c ontrolPID(I nputSe t, OutFile) wsclea nup('wsrml*.jpeg', 1); %parametr os de tiempo Ts= str 2double(I nputSe t.Ts) ; Tt= str 2double(I nputSe t.Tt) ; %parametr os de la trayector ia Xo1=str2double(InputSet.Xo1); Xm1= str 2double(I nputSe t.Xm1); to1=str2double(InputSet. to1); phi1= str 2double(I nputSet.phi1); tray=InputSe t.Trayectoria ; %parametr os de l contr ola dor de e levac ion elevacion='PID'; %define cual c ontrolador se va a utilizar

59

%parametr os de l contorla dor PID de e levac ion Kp1=str2double(InputSet.Kp1); %c onsta nte de proporc ionalidad Kd1=str2double(InputSet.Kd1); %1ra consta nte de derivacion Kdd1= 0.12;%2da constante de derivacion Ki1=str2double(InputSet.Ki1); %Consta nte de integrac ion Tdf1=0.05;%filtro de derivacion %Varia ble s que determ ina n el filtro de entrada (off set) ircscale =1024; % irc sca ling az_offse t=- 0.7; % a zimuth off set el_off set=-0.25; % e lev offse t Fts=0.1; Fnum= 9.53674e- 007; Fden= 1; Fnum = [1/irc scale]; % input f ilter Fden = [1] ; Fts = 0.1; u10 = 0.50; % maim motor - offse t u20 = -0.18; % aux. m otor - offset %valores de las variables para que f uncione perfectame nte %%%%%%%%%%%%%%%%%%%%%%%%%%%% % defaults %%%%%%%%%%%%%%%%%%%%%%%%%%%% %Var iables que determinan el f iltro de e ntrada (off set) ircscale =1024; % irc sca ling az_offse t=- 0.7; % a zimuth off set el_off set=-0.25; % e lev offse t Fts=0.1; Fnum= 9.53674e- 007; Fden= 1; Fnum = [1/irc scale]; % input f ilter Fden = [1] ; Fts = 0.1; u10 = 0.50; % maim motor - offse t u20 = -0.18; % aux. m otor - offset rtload('mf614',65535,[0 1 1 1 1 1 1 1 1 250000 250000 250000 250000 3 3 3 4]) ; % instala el driver del helicoptero rtout(5,20000); %PWM frequenc ies rtout(7,20000); rtout( 8,0); %%%%%%%%%%%%%%%%%%%%%%%%%%% % Tiempo de muestre o %%%%%%%%%%%%%%%%%%%%%%%%%%% TT = floor( Tt/Ts); % nr. muestra s w1=Xo1+ zeros( TT,1); % trayectoria por defec to z= zeros(TT,4) ; %%%%%%%%%%%%%%%%%%%%%%%%%%% % Trayectoria %%%%%%%%%%%%%%%%%%%%%%%%%%% TT = floor( Tt/Ts); % nr. of samples w1=Xo1+ zeros( TT,1); % defa ult trajectory %%%%%%%%%%%%%%%%%%%%%%%%%%% % Trajectory %%%%%%%%%%%%%%%%%%%%%%%%%%% if strcmp(tray,'Consta nte') % constante

60

w1= zeros(TT,1) ; elseif strcmp( tray,'Esca lon') % esca lon w1=(1:TT)'>(to1/Ts) ; elseif strcmp( tray,'Rec tangulo') % recta ngulo w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); w1 = sign( w1) ; elseif strcmp( tray,'Tria ngulo') % tr iangulo w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); w1 = a sin(w1)/( pi/2) ; elseif strcmp( tray,'Se no') % se no w1 = sin((1:TT)'*(2*pi*Ts/to1)+phi1); elseif strcmp( tray,'Ruido') %r uido w1=c umpr od( 1-2*(rand(TT,1)<2*Ts/to1(1))); end w1=w1*Xm 1+Xo1; % se le suma offse t y la amplitud %DEFI NI R CUAL CONTROLADOR DE ELEVACION SE VA A USAR% [ Cnumy1,Cdeny1,Cnumw1,Cdenw1]=pid2z(Ts,Kp1,Ki1,Kd1,Kdd1,Tdf1) ; %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %Modulo de tiempo Real %%%%%%%%%%%%%%%%%%%%%%%%%%%%%% rtclear; rtdef(19,'out',0.1,[11 12]); % habilita motores rtwr(19,[ 1 0]) ; rtdef('w1',TT,1) ; % elevacion desea da rtwr('w1',w1) ; rtdef('u1',1,1); % offset motor principal rtwr('u1',u10); rtdef('el_off',1,1) ; % offset elevacion rtwr('el_off',el_off set) ; rtdef(1,'tfin',Ts,[.. . 211 .. . ],Cnum w1,Cdenw1); rtlink( 1,'w1'); rtdef(3,'mvtf in',Fts,[... % elevacion 9 .. . % y(elev) 253 .. . % el_offset ],[Fnum ;1],Fden) ; rtlink( 3,'el_off',253)

61

rtdef(5,'tfin',Ts,[.. . % filtr o de ele vacion 221 .. . % y(elev) ],-Cnumy1,Cdeny1); rtlink( 5,3) rtdef(7,'mvtf in',Ts,[... 231 .. . % yf(elev) 233 .. . % wf(elev) 235 .. . % offs(ele v) ],[1;1;1],1) ; rtlink( 7,5,231) rtlink( 7,1,233) rtlink( 7,'u1',235) rtdef(9,'out',Ts,[.. . % contorlador logico de la sa lida DC 251 .. . % u(elev) ]) rtlink( 9,7,251) rtdef(10,'out',Ts,[ ... % contorlador fisico de la salida DC 6 .. . % u(elev) ]); rtlink( 10,9) rtdef(15,'in',Ts,[.. . 205 .. . % y(elev) 207]);.. . % u(elev) rtlink( 15,3,[ 205]) rtlink( 15,9,[ 207]) rtdef(' z',TT,2,1); % vec tor en e l que se graba los da tos de los se nsores rtlink(' z',15) %%%%%%%%%%%%%%%%%%%%%%% % se inicia el exper imento %%%%%%%%%%%%%%%%%%%%%%% rtstart([7 9 10 19]) % inic ian los motores gnext= 0; % conta dore s graf icos gstep=max([TT/50,0.3/Ts,1]); hold off clf figure( gcf) subplot(111) plot(Ts*(1:TT),w1,'-b'); axis([ 0 TT*Ts -0.25 0.25]) title('He lic opter elevation') grid xlabel(' time [s]') ylabel('angle [-]') hold on t = Ts*(2+length( Cde ny1)); rtwr(7,'time', t) rtwr(7,'t',0) t=1; t_= 0; t__=0; rtstart([1 3 5]) % se inician los se nsores while (r trd( 7,'t')==0)

62

y1__=rtrd(3,'y '); end rtflush % inic ia la gra bacion rtstart(15) %%%%%%%%%%%%%%%%%%%%%%% while t<TT % loop que hace que e l experime nto f unc ione %%%%%%%%%%%%%%%%%%%%%%% if t>=gnext y1=r trd( 3,'y'); plot([t;t__] *Ts,[y1;y1__],'-g','erasemode','none') drawnow y1__=y1; t__=t; gnext=t+gste p; end t_=t; while t== t_ t=(rtr d(15,'t')); end end % for z = rtr d('z'); rtunlink([ 10 ]) % para motores rtwr(10,'y',[0]); while (r trd( 15,' t') < t+ 2);e nd rtclear % rese t de timers hold off clg %%%%%%%%%%%%%%%%%%%%%%%%%%% % grafica de resultados %%%%%%%%%%%%%%%%%%%%%%%%%%% angulo= z(:,1); ejeymax=max(angulo); ejeymin=min(angulo); aux=ma x(w1); aux2=min(w1); ejeymax=max(ejeymax,aux); ejeymin=min(ejeymin,a ux2); ejeymax=ejeymax+(0.35-ejeymax)/10; ejeymin=ejeymin+(-0.3+ejeymin) /10; Fig = figure('visible','off'); hold off clf figure( gcf) set(gcf ,'name','H E L I C O P T E R : 1- DF linear contr ol','number title','off') subplot(211) % elevacion plot((1:TT)*Ts,w1,'-b',... (1:TT)*Ts,z(:,1),'-g') grid xlabel('Tiempo [s]') axis([ 0 TT*Ts ejeymin ejeymax]) text(0,1,'Elevac ion','units','norma lize d','hor izonta lalignment','left','vertica lalignme nt','bottom','fontweight','bold')

63

angulo2=z( :,2); ejeymax2=max(angulo2); ejeymin2=min(angulo2); ejeymax2=ejeymax2+(1.6-ejeymax2) /10; ejeymin2=ejeymin2+(- 1.5+ejeymin2)/10; subplot(212) % motor principal plot((1:TT)*Ts,z(:,2),'-r') grid axis([ 0 TT*Ts ejeymin2 ejeymax2]) % voltaje motor axis(a xis) text(0,1,'Voltaje del motor principa l','units','norma lize d','hor izonta lalignment','left','vertica lalignment','bottom','fontwe ight','bold') k=[0.01 1.00]; % Explicac ion de colore s de los grafic os l=[0 0.05] ; %%%%%%%%%%%%%%%%%%%%%%%%%% v = axis; axpos = ge t(gca,'position'); k = v(1) + ( k-axpos( 1))*( v(2)- v(1))/axpos(3); l = v(3) + (l-a xpos(2))*(v(4)-v(3))/axpos(4) ; k0= k(1) ; dk= diff( k); l0= l(1) ; dl= diff( l); line(k([1 2 2 1 1]) ,l([ 1 1 2 2 1]),'line style','-','color',[1 1 1] ,'clipping','off') x= k0+dk/3*(( 0.7:3))' ; y=l0+dl/2* [ 1 1 1]' ; text(x,y,['Nivel DC: ';' Angulo Sa lida ';' Angulo Entrada '],'horizonta lalignment','right') x=[x x+dk*0.07] ; y=[y y]; line(x(1,:),y(1,:),'c lipping','off','color',[1 0 0]) line(x(2,:),y(2,:),'c lipping','off','color',[0 1 0]) line(x(3,:),y(3,:),'c lipping','off','color',[0 0 1]) subplot; axis; hold on; draw DC=z(:,2); tiempo= Ts*(1:TT); Angulo_salida=angulo'; Angulo_entra da= w1'; Nivel_DC= DC'; valor=[tiempo;Angulo_entrada ;Angulo_salida ;Nive l_DC]; fid = fopen('datos_controlPID.xls','w'); fprintf(fid,'Tiempo Angulo de e ntra da Angulo de salida Nivel DC \n'); fprintf(fid,'%f %f %f %f \n',valor); status = fclose(fid); s.GraphFile Name = spr intf('hedemo%s.jpe g', InputSet.mlid) ; wsprintjpeg( Fig, s.Gra phFile Name); s.GraphFile N