ADQUISICIÓN DE IMÁGENES MEDIANTE CAMARA PAN · PDF fileadquisiciÓn de imÁgenes mediante camara pan-tilt montada sobre un carro lineal. i. ruiz. 10 de marzo de 2003

ADQUISICIÓN DE IMÁGENES MEDIANTE CAMARA PAN-TILT MONTADA SOBRE UN CARRO LINEAL.

I. Ruiz.

10 de marzo de 2003.

Llegó el día. Terminé la carrera, y de repente me veo convertido en Ingeniero. Después de tanto tiempo y trabajo, hay mucha gente a la que agradecerle el apoyo que me ha dado en todos estos años. Por supuesto, a mi familia, especialmente a mis padres, que no perdieron la paciencia, pese a los motivos que tuvieron, e hicieron posible que hoy llegue a ser lo que soy. Y a mis abuelos, que tantas ganas tenían de verme terminar (Ya es hora de abrir esa botella de vino que guardáis desde hace tanto). También a los compañeros de proyecto, Angel, Vladi, Abdel, Timmen y Bert, con los que he pasado momentos memorables, y los que nos quedan. Y a los nuevos compañeros de este año, mis primeros alumnos, que me han aguantado en estos últimos días de agobio antes de acabar todo el trabajo: gracias Jose, David, Ricardo, Fernando, Marta, Thomas. A mis amigos, por celebrarlo conmigo cuando las cosas iban bien, y por aguantarme el rollo cuando no. A Carlos, por apretarme las clavijas cuando era necesario, por enseñarnos que a buscarnos la vida, y por tantos “Todavía no esta listo” que ha tenido que soportar. A Alvaro, por escucharme en los malos momentos, y demostrar que en la Escuela no todos los profesores son iguales. Y a Yoli, porque si no, ya sabemos lo que pasará (TQM).

Iván

RESUMEN El sistema sobre el que se trabaja está pensado para hacer seguimiento de objetos, controlado desde un ordenador personal. Dicho sistema de seguimiento consta de dos partes diferenciadas. Por un lado, el sistema de Percepción Artificial, una cámara Pan-Tilt Sony Autoevi-D31. Por otro lado, para poder realizar la autocalibración de la cámara, se implementó un carril lineal que permitía que la cámara se moviese en una trayectoria conocida, obteniendo así las imágenes necesarias para la autocalibración. Todo ello, controlado con una aplicación implementada por los propios proyectantes. El objetivo primordial del presente proyecto es el de crear una aplicación que sirva de continuación (y también fusión) de éste y otros proyectos realizados en el pasado por anteriores proyectantes de este mismo Departamento. Se debe llegar un paso más allá de lo que lo hicieron los anteriores compañeros, implementando nuevas utilidades de control del sistema y mejorando las ya existentes, para obtener prestaciones cada vez mayores. Es precisamente esta aplicación la que representa la continuación de los distintos proyectos. A partir de los trabajos desarrollados por anteriores proyectantes, se obtuvieron distintas aplicaciones que controlaban por separado partes concretas del sistema, que hay que fusionar en una nueva aplicación que tenga todas las prestaciones individuales de las anteriores. También cabe destacar que originalmente el ordenador con el que se controlaba el sistema, Heissenberg, estaba en la red del GVA, basada en Windows NT. Esta red se ha mejorado, cambiando el sistema operativo de los equipos a Windows 2000, con lo que también se tuvo que cambiar el sistema operativo de Heissenberg.

ABSTRACT The main goal for the present project is creating an application, being the next step (And maybe also the fusion) for this and another projects realized in previous years by some other students of this Department. This new application has to reach higher features, developing new system control utilities, and improving those already developed. The system to work on is prepared to make an object tracking, controlled from a personal computer. This tracking system has two separated parts. On the one hand, there is an artificial vision system, which is implemented with a Pan-Tilt camera Sony Autoevi-D31. On the other hand, and to manage the camera self-calibration, there is a linear rail. This rail allows the camera to move in a known trajectory, getting that way the necessary images to start the self-calibration process. All that is controlled by an application developed by the students of the Department. It is exactly this application the greatest representation of that continuity of several projects. From previous students, different applications were obtained, which controlled separately particular parts of the system, either the camera, or the rail. This particular controls, has to be fused together in a brand new application, with all the individual features of the preceding ones. It has also to be thrown into relief that originally, the computer that controlled the whole system, HEISSENBERG, was allocated in the GVA network, based on Windows NT. That network was improved, migrating the operative systems to Windows 2000. That meant Heissenberg’s operative system had also to be changed.

INDICE GENERAL

- Resumen.

- Abstract.

- Indice General.

1.- Introducción al sistema de Percepción Artificial.

1.1.- Marco del proyecto.

1.2.- Objetivos del proyecto.

1.3.- Estructura de los capítulos.

2.- Estado de la técnica.

2.1.- Necesidad de la estereoscopia.

2.1.1.- El modelo estándar de adquisición de imágenes.

2.2.- Control del carril lineal.

2.2.1.- Origen de carril lineal.

2.2.2.- Programas de control del carril.

2.2.2.1.- Programa de control de motores.

2.2.2.2.- Programa ControlVision3D de Collado.

2.3.- Control del sistema de visión.

2.3.1.- Origen del sistema de visión.

2.3.1.1.- Desarrollo de Alamo.

2.3.1.2.- Desarrollo de Yubero.

2.3.2.- Programas de control de la cámara.

2.3.2.1.- Programa Control EVI-D31 de Yubero.

GVA-ELAI-UPM@PFC070-03 1

Indice general. Iván Ruiz Tejedor

2.3.2.2.- Programa Autoevi de Yubero.

2.4.- Mejoras necesarias.

2.4.1.- Implementación del carril lineal.

2.4.2.- Desarrollo de la nueva aplicación.

2.4.2.- Instalación de Windows 2000.

2.5.- Futura evolución.

3.- Descripción del sistema de Percepción Artificial.

3.1.- Descripción del Carril Lineal.

3.1.1.- Tipos de motores.

3.1.1.1.- Control de motores.

3.1.1.2.- Métodos de control de potencia.

3.1.1.3.- Métodos de control de velocidad.

3.1.2.- El motor Maxon-698.

3.1.3.- El controlador digital SMCC-01.

3.1.3.1.- Componente de control.

3.1.3.2.- Componente de potencia.

3.1.4.- El integrado LM629.

3.1.4.1.- Especificaciones técnicas.

3.1.4.2.- Generación de trayectorias.

3.1.4.3.- Seguimiento de la posición.

3.1.4.4.- El regulador PID.

3.1.4.5.- Alimentación del motor con una señal PWD.

3.1.5.- El filtro PID.

3.1.5.1.- Funcionamiento del regulador PID.

3.1.5.2.- Aplicación al presente sistema.

3.1.5.3.- Método continuo.

3.1.5.4.- Método digital directo (Método de Truxal).

3.1.6.- El integrado 82C55A de Intel.

3.1.6.1.- Introducción.

3.1.6.2.- Especificaciones técnicas.

3.1.6.3.- Funcionamiento general.

2 GVA-ELAI-UPM@PFC070-03

Iván Ruiz Tejedor Indice general.

3.1.6.4.- Funcionamiento en Modo 0.

3.1.6.5.- Aislamiento optoelectrónico.

3.1.6.6.- Aplicación al sistema actual.

3.1.7.- Implementación del carril lineal.

3.1.7.1.- Vista general del sistema.

3.1.7.2.- Circuitos eléctricos.

3.1.7.3.- Componentes del carril.

3.1.7.4.- Puesta en marcha del sistema.

3.1.7.5.- Problemas surgidos.

3.1.8.- Instalación de Tinyport.

3.2.- Descripción del Sistema de Visión.

3.2.1.- Introducción al sistema.

3.2.2.- La cámara Pan-Tilt.

3.2.2.1- Especificaciones técnicas.

3.2.2.2.- Funciones añadidas.

3.2.2.3.- Conexión al equipo.

3.2.3.- La tarjeta Meteor.

3.2.4.- Las librerías MIL.

3.2.5.- Control del sistema. El protocolo VISCA.

3.2.5.1.- Definiciones del protocolo.

3.2.5.2.- Composición del mensaje.

3.2.5.3.- Tipos de órdenes.

3.2.5.4.- Flujo de información en la transmisión.

3.2.5.5.- Lista de órdenes en VISCA.

3.3.- Conclusiones.

4.- Modelización del sistema.

4.1.- Necesidad de la modelización.

4.1.1.- Fundamentos del modelado de objetos.

4.2.- Necesidad de la independencia.

4.3.- Introducción a la modelización.

4.3.1.- ¿Qué es UML?.


Indice general. Iván Ruiz Tejedor

4.3.1.1.- Definiciones.

4.3.1.2.- Bases del UML.

4.3.2.- Objetos y mensajes en UML.

4.3.3.- Modelado de sistemas complejos.

4.3.3.1.- Métodos de organización.

4.3.4.- Tipos de diagramas.

4.4.- Modelado del sistema.

4.4.1.- Planteamiento de requisitos.

4.4.2.- Diagrama de casos de uso.

4.4.3.- Diagrama de clases.

4.4.4.- Diagrama de secuencia.

4.4.4.1.- Ejemplo 1 : ejecución de un movimiento del carril.

4.4.4.2.- Ejemplo 2 : ejecución de un movimiento de la cámara.

4.5.- Conclusiones.

5.- Programa de control del sistema.

5.1.- Instalación de Windows 2000.

5.1.1.- Automatización del servicio Tinyport.

5.1.2.- Instalación de las MIL.

5.2- Primeras mejoras sobre los programas existentes.

5.3.- Aplicación ControlIntegral.

6.- Conclusiones.

7.- Futuras mejoras.

Bibliografía

Apéndice A.- Pseudocódigo de la aplicación ControlIntegral.


Capítulo 1. Introducción al sistema de percepción artificial. El presente proyecto se desarrolló en el Grupo de Visión Artificial del Departamento de Electrónica, Automática e Informática Industrial de la Escuela Universitaria de Ingeniería Técnica Industrial de la U.P.M. El fin último de este proyecto es la implementación de un vehículo aéreo, totalmente autónomo, destinado a la revisión de las líneas de transporte de electricidad en alta tensión. Este vehículo, equipado con un sistema de visión artificial, debería ser capaz de, a partir de las imágenes recogidas por la cámara Pan-Tilt, realizar un procesamiento tridimensional, según el cual poder reconstruir el escenario en el que se debe desenvolver el aparato. Esta tarea de revisión de líneas catenarias de tensión sólo puede realizarse hoy en día mediante el uso de helicópteros, con el riesgo que ello conlleva para las personas que lo pilotan. Este aparato reduciría drásticamente dichos riesgos, además de presentar ventajas económicas inmediatas, por el ahorro de peso que supondría. Este planteamiento no ha escapado a otras universidades o empresas, que ya disponen de prototipos de vehículos aéreos autónomos en distinto estado de desarrollo. En cualquier caso, la tarea no es sencilla y resulta demasiado grande para ser asumida por un solo estudiante. Es por eso que se ha planteado en distintas etapas, más asequibles, y acordes con las capacidades de los proyectantes del Departamento, haciendo que el resultado de cada año se acerque cada vez más al objetivo final. 1.1 Marco del proyecto. En este proyecto, se tratará de implementar una aplicación de control para los dos dispositivos que componen el sistema actualmente. Por una lado, tenemos un sistema de visión, compuesto por una cámara Pan-Tilt, además de los dispositivos necesarios para transmitir las imágenes que recoge al ordenador, y poder controlarla desde el mismo. Por otro lado, tenemos un sistema de movimiento controlado, para poder desplazar la cámara a posiciones concretas. Este movimiento resulta clave para el desarrollo del sistema, como se explicará más adelante.


Introducción al sistema Iván Ruiz Tejedor de Visión Artificial.

Así pues, se implementará una comunicación por puerto serie con la cámara, a través del uso de las librerías MIL. Se desarrollará un programa en C++, en modo consola, a través del compilador de Microsoft Visual C++, Ver. 6.0, y bajo el sistema operativo Windows 2000. Todo este proceso de programaciones llevará a cabo después de hacer una modelización del problema bajo los estándares de UML. 1.2 Objetivos del proyecto Como ya se mencionó anteriormente, el presente proyecto pretende ser una fusión de los programas y utilidades desarrolladas por los antiguos proyectantes del GVA. Estas aplicaciones, destinadas a controlar partes individuales del sistema, deben dar lugar a una nueva que aúne todas estas capacidades de control. La nueva aplicación, implementada en modo consola, permitirá el manejo tanto de la cámara como del carril lineal. Pero todo ello debe hacerse teniendo en cuenta que el sistema va a seguir siendo mejorado por los siguientes proyectantes que se vayan incorporando al Departamento. Por tanto, debe hacerse un programa claro, fácil de entender, para permitir la incorporación de mejoras por parte de estos nuevos desarrolladores. para ello, deberá buscarse la mayor independencia posible entre las partes que compongan la nueva aplicación, como se explicará en el capítulo dedicado a UML 1.3 Estructura de los capítulos En el capítulo 2 se dará cuenta del estado inicial del proyecto en el momento en el que se inicio la realización del proyecto. Se explicarán las funciones disponibles en las aplicaciones desarrolladas por los antiguos proyectantes, y las mejoras a desarrollar en cada una de ellas. También se detallará la necesidad de integración del equipo que controla el sistema, Heissenberg en el laboratorio del Departamento, con la adaptación necesaria a las nuevas mejoras introducidas en el entorno. En el capítulo 3 se detallarán los componentes del sistema de Percepción Artificial que se va a tratar. Se explicarán las funciones que tienen cada uno de los elementos utilizados, las conexiones necesarias entre ellos, los protocolos de comunicación existentes. También se detallará la implementación del carril lineal, que hasta entonces no se había usado en este proyecto, sino en otros del departamento, con un fin distinto. Asimismo, se hará una pequeña introducción a las librerías MIL (Matrox Imaging Library), que permiten el control de determinadas capacidades de la cámara En el capítulo 4, se explicará qué es UML, qué se busca con la modelización, los diagramas más usados en UML y como se modeló el sistema en este lenguaje de programación. Se mostrarán también los diagramas obtenidos tras el estudio del sistema y se mostrarán algunos ejemplos del modelo obtenido finalmente. En el capítulo 5 se detallarán las aplicaciones que finalmente se han desarrollado en este proyecto, así como las mejoras que se hicieron previamente a las aplicaciones de control individual de los elementos del sistema.


Iván Ruiz Tejedor Introducción al sistema de Visión Artificial.

En el capítulo 6 se presentarán las conclusiones a las que se llegó tras el trabajo realizado durante la realización de este proyecto. En el capítulo 7 se apuntarán las posibles líneas de desarrollo para el futuro del proyecto, para que sirvan de indicación a los futuros proyectantes que se irán incorporando al Departamento. Finalmente, en el apéndice del proyecto se documentará el pseudocódigo de la aplicación de control integral del sistema.


Capítulo 2. Estado de la técnica. A continuación, intentaremos aclarar el planteamiento de partida del proyecto, así como definir las aplicaciones de control ya existentes, desarrolladas por los antiguos compañeros del Departamento. Con ellas, se pueden controlar de manera individual los componentes del sistema, siendo el gran reto avanzar un paso más, desarrollando una nueva aplicación, que permita tener en un solo programa la posibilidad de manejar todos los dispositivos del sistema. Con este paso inicial cumplido, en el futuro únicamente se necesitaría añadir capacidades a esa nueva aplicación, hasta lograr un programa que permitiese la programación completa del dispositivo de seguimiento. Como ya se comentó anteriormente, el fin último del proyecto es la creación de un vehículo autónomo, capaz de interpretar el entorno que le rodea, y de esa forma inferir su situación en el espacio. para ello, sólo se puede valer de las imágenes que obtenga con su sistema de visión. Con él debe captar imágenes de su entorno y ser capaz de procesarlas sin ayuda externa, usando únicamente sus propios recursos. Ese procesamiento debe dar como resultado una rutina de actuación, en función de las órdenes recibidas y la situación observada. El vehículo debe ahora ser capaz de saber qué obstáculos le rodean, qué ruta es la más asequible, etc. Todo ello, sin ninguna actuación externa, puesto que pretendemos crear un vehículo autónomo. Esta sería la solución ideal que persigue el Departamento, a través de varios proyectos individuales. La situación actual de desarrollo del mismo, todavía está unos pasos más atrás. A día de hoy, se encuentra definido e implementado el sistema de visión. Con él pueden hacerse casi todos los trabajos para los que se pensó este sistema, como es el seguimiento de cables y algunos otros que en principio no estaban previsto, como el seguimiento de haces de luz. También se encuentra en su fase inicial el sistema de movimiento que, aunque solamente permite un movimiento lineal, es lo suficiente como para acometer el diseño del proceso de autocalibración de la cámara, necesario para seguir avanzando.

Estado de la técnica. Iván Ruiz Tejedor

2.1 Necesidad de la estereoscopia. Nuestro dispositivo va a moverse en un sistema de tres dimensiones, partiendo de un sistema de adquisición de imágenes con únicamente dos dimensiones. Por tanto, se debe implementar algún mecanismo que permita al sistema hacer una composición de la tercera dimensión, partiendo de las dos conocidas. Este problema de falta de información no es algo nuevo, puesto que todos los seres vivos de la naturaleza se han tenido que enfrentar a él para poder sobrevivir. para ello, la naturaleza dotó a las especies de un sistema de estereoscopia, a partir del cual poder procesar las imágenes obtenidas y calcular las coordenadas de la tercera dimensión. Y como en casi todos los casos, resulta más fácil copiar a la naturaleza que intentar desarrollar sistemas nuevos. En el caso que nos ocupa, la solución de la estereoscopia es una solución bastante sencilla de implementar, económica y asequible. Este proceso consiste en la superposición de dos imágenes, la cual genera una serie de diferencias lógicas, si se tiene en cuenta que se toman desde puntos distintos. Con una análisis exhaustivo de estas diferencias, se puede implementar un modelo de tres dimensiones bastante aproximado a la realidad. Por tanto, puede decirse que la visión estereoscópica es un conjunto de procesos que permite recuperar información tridimensional a partir de dos o más vistas bidimensionales de una misma escena. El proceso consta de una serie de pasos, como se detalla [LOPEZ88] : • Calibración de los parámetros intrínsecos y extrínsecos involucrados del sistema de adquisición de imagen bidimensional. • Rectificación de la geometría epipolar, para simplificar tanto como sea posible la búsqueda de correspondencias entre las imágenes • Correspondencia entre puntos de ambas imágenes, que proporcionan un mapa de disparidades. En este punto, cuantas más disparidades se tengan, mayor fiabilidad tendrá el resultado final • Reconstrucción de la escena 3D, es decir, el cálculo de las profundidades a partir de las disparidades. Como se ve pues, es necesario un proceso que permita determinar las irregularidades que se introducen en el cálculo de distancias debido a los pequeños defectos de fabricación, irregularidades de los materiales, etc. Este proceso debe ser totalmente automático, puesto que nuestro vehículo es autónomo. El proceso consiste en capturar dos imágenes distintas de un escenario conocido. En este escenario se conocen todas las medidas que se captan con la cámara, así que cualquier variación de la distancia obtenida en el proceso respecto de la medida real, permite hallar la irregularidad que se introduce en el sistema debido a los fallos de fabricación. Por descontado, cuanto más diferentes son las dos imágenes, más fácilmente se pueden medir las distancias en el plano perpendicular a las imágenes, con lo cual resulta más exacto todo el proceso. Es por eso que el sistema de Percepción Artificial debe disponer de algún sistema de movimiento controlado, que permita realizar la autocalibración del dispositivo de visión, antes de acometer movimientos más complejos. En el caso de este proyecto, se utilizó un carril lineal movido por un motor eléctrico, y


Iván Ruiz Tejedor Estado de la Técnica.

controlado por una aplicación en el mismo ordenador que controla la cámara. De este modo se puede programar el sistema para que realice la adquisición de dos imágenes del mismo escenario, según lo que se conoce como Modelo estándar 2.1.1 El Modelo estándar de adquisición de imágenes: Este modelo consiste en tomar dos imágenes con dos cámaras situadas paralelas una a la otra, y perpendiculares al escenario sobre el que se trabaja. Con las imágenes tomadas, se realiza la triangulación del objetivo captado, según el esquema de la Figura 2.1

Figura 2.1

En este caso, tendríamos que :

• L y R, son dos cámaras, con ejes ópticos paralelos. Se define f como la distancia focal de ambas cámaras (Distancia entre el objeto captado y el foco de la cámara). • La línea base, que conecta los dos centros de las lentes, es perpendicular los ejes ópticos (eje formado por la unión del centro del objeto con el centro del foco de la cámara).

• b es la distancia entre los dos centros ópticos.

• XZ es el plano que contiene a los ejes ópticos, el plano XY es paralelo al plano de la imagen en ambas cámaras, el eje X corresponde con la línea base y el origen O del sistema de coordenadas del mundo es el centro de la lente en la cámara de la izquierda.

Con esta configuración, podemos obtener unas ecuaciones :

Z = 21 xx

fb−⋅

X = fZx1



Y = fZy1

De modo que podemos calcular las distancias del escenario conociendo la situación de las dos cámaras. Pero para el proyecto que nos ocupa, hay una propiedad muy interesante, económicamente hablando, y es el hecho de que este modelo de dos cámaras puede simplificarse. En la vida real, los objetos están normalmente en movimiento, por lo que sí que es necesario tener dos “dispositivos de adquisición de imágenes”, como son nuestros ojos. Pero en un escenario artificial, podemos hacer que todos los objetos sean estáticos, de forma que sólo necesitamos tomar las imágenes desplazando una de las cámaras, y almacenando la primera imagen obtenida hasta tomar la segunda, y empezar el proceso de autocalibración. Esta solución es la que se adoptó en este proyecto, puesto que es más económica, y además permite comenzar a investigar el movimiento posterior de todo el sistema (Si se consigue hacer un primer movimiento controlado, aunque simplemente sea lineal, el desarrollo de un sistema de movimiento completo es mucho más asequible, puesto que sería la composición de dos movimientos lineales controlados). 2.2 Control del carril lineal El sistema empleado en este proyecto, según lo descrito anteriormente, está formado por dos partes claramente separadas. Por un lado, el sistema de adquisición de imágenes (cámara Pan-Tilt), y por otro, el sistema de movimiento para autocalibración (Carril lineal). Ambas partes, desarrolladas ya por anteriores proyectantes, disponen de sus aplicaciones de control individual, teniéndose ahora que aunar el control de los dos dispositivos en una sola aplicación. A continuación, se detallará el origen de estas partes del sistema, así como de los programas existentes, fruto del trabajo de los anteriores estudiantes del Departamento. 2.2.1 Origen del carril lineal. Fue diseñado inicialmente por Collado, para ser utilizado en otro proyecto dentro del GVA, llamado Adquisición tridimensional de piezas industriales [COLLA00]. En la figura 2.2, se puede ver una imagen del mismo :



Figura 2.2 : El carril lineal original

En este sistema, el carril desplazaba una plataforma en la que se colocaba una pieza industrial, y sobre la que se aplicaba un haz láser. Al moverse el carril, la plataforma se desplazaba, siendo la pieza cortada por el láser en distintos puntos de su contorno. El perfil de la pieza marcado por el láser era captado por una cámara, que realizaba una reconstrucción tridimensional punto por punto de la misma. El sistema del carril podía ser plenamente válido para el presente proyecto, excepción hecha de algunas modificaciones en cuanto al tamaño y la velocidad del movimiento. Mientras que en el proyecto original las dimensiones no necesitaban ser demasiado grandes, en el caso que nos ocupa, cuanto mayores sean las distancias, mayor fiabilidad tendrá el resultado obtenido. Y si bien antes era necesario que la plataforma se moviese lentamente, para obtener cuantas más tomas mejor, ahora la velocidad no es determinante para el funcionamiento del sistema. En cualquier caso, se detallarán más adelante las características del nuevo carril diseñado a partir de éste. 2.2.2 Programas de control del carril. El programa de control del carril no es el único que se puede usar para mover el carril lineal. A continuación se enumerarán los programas existentes, con sus ventajas e inconvenientes. 2.2.2.1 Programa de control de motores. Este programa fue originalmente pensado para realizar practicas en el laboratorio de Servosistemas de la E.U.I.T.I. Está desarrollado bajo Borland C++, con lo cual es un programa bastante sencillo, únicamente permitía controlar un motor parecido al del carril. En la figura 2.3 se puede ver una imagen del programa.



Figura 2.3

Como su nombre indica, lo que se controlaba con este programa, únicamente era un motor, como el que se usa en el carril lineal del sistema que aquí se estudia. Por tanto, en el sistema original, no se usaba ningún carril, y el destino único de la aplicación era el control de un motor sin ningún tipo de engranaje reductor. Los desplazamientos, al ser el giro de un motor, se realizaban siempre en grados, en lugar de mover distancias, como es necesario en el caso del carril. Obviamente, a la hora de manejar el carril, este programa presentaba una gran desventaja, y es el hecho de que no se podían controlar bien las distancias movidas, puesto que entraba en juego un engranaje reductor. Así, las distancias dadas como parámetro, no coincidían con los movimientos reales. 2.2.2.2 Programa ControlVision3D de Collado Este programa fue desarrollado por el mismo alumno que implementó el carril lineal original, en el que se basó el de este proyecto. Con dicho programa, se debía mover una pieza, para poder realizar la reconstrucción 3D de la misma. En este caso, ya se trata de una aplicación mucho más versátil, puesto que incorpora más comandos que la anterior. Contiene ya algún método de calibración de la cámara, así como la posibilidad de llevar el carril a un punto inicial, desde donde poder mover distancias con cierta exactitud. Pero de nuevo, se tropieza con el mismo problema que en el caso anterior, puesto que todos los movimientos se realizaban en grados, en lugar de en unidades de longitud, con lo que resultaba difícil predecir el desplazamiento. Se puede ver una imagen de la aplicación en la figura 2.4 :



Figura 2.4

Aunque la utilidad de estas aplicaciones es indudable, no es menos cierto que requieren mejorar el aspecto de las unidades de movimiento, como se comentó anteriormente, para poder lograr movimientos precisos del carril. Sin esta exactitud, el proceso de autocalibración no tiene ningún sentido. Más adelante, se explicarán las mejoras que se introdujeron en estos programas, como paso previo al desarrollo de la aplicación de control completo del sistema. 2.3 Control del sistema de visión Como ya se comentó anteriormente, el sistema de visión está implementado con una cámara Pan-Tilt. Esta cámara tiene la posibilidad de desplazar su foco horizontal y verticalmente. Es la encargada de suministrar al sistema las imágenes necesarias para realizar primeramente el proceso de autocalibración, y una vez realizado, procesar cómo es el entorno que rodea al sistema, para así poder realizar el seguimiento de catenarias que se persigue. A esta posibilidad de seguimiento se le añadió otra más, que permitía realizar el seguimiento de un puntero láser, sobre la base de la binarización que se hace de la imagen captada con la cámara. De todas estas posibilidades, se dará cuenta a continuación. 2.3.1 Origen del sistema de visión. El sistema de visión usado en el proyecto fue implementado en dos fases, por dos antiguos proyectantes del Departamento. Primeramente, Alamo [ALAMO00] implementó una primera aproximación al problema del seguimiento de cables y de un haz de luz. Posteriormente, Yubero [YUBER01] aplicó mejoras al programa existente, resultando de ello una aplicación plenamente operativa, que permitía poner en marcha mecanismos autónomos de seguimiento con la cámara.



2.3.1.1 Desarrollo de Alamo. Para realizar el seguimiento del punto medio de una catenaria, primero se necesitaba simplificar el problema. para ello, se consideró el sistema como una línea catenaria, que la cámara captaba sobre un fondo blanco. Con esta imagen modelo, se aplicaba un algoritmo, llamado Algoritmo de Burns, que permitía separar la imagen del cable, más oscura, del fondo de la misma, totalmente blanca. Esto se consigue analizando los niveles de grises de la imagen, y contando con el hecho de que en el límite del cable, el salto de grises, del negro del cable al blanco del fondo de la imagen, era mucho más grande que en el resto de la imagen. Con esta maniobra, podía saberse qué parte de la imagen era el cable y qué parte era sólo fondo de la imagen, sin ninguna utilidad. Pero quedaba el problema de cómo identificar el centro de la catenaria a seguir. El cable, originalmente, tiene una forma difícil de modelar. El sistema debe seguir el centro de gravedad del cable captado, así que se necesita reducir lo captado a una forma simplificada, fácil de analizar. Así pues, se aplicó una descomposición del cable, por la que la forma curva pasaba a modelizarse como un conjunto de líneas rectas, de las cuales, componiendo centros de gravedad ya sí se podía obtener el centro de gravedad total del cable, permitiendo que el sistema pudiese realizar el seguimiento adecuadamente. Por otro lado, se implementó un sistema de seguimiento de imágenes, sobre la base de la binarización de la imagen captada por la cámara. Este proceso consistía en asignar a cada píxel de la imagen un nivel de gris, para simplificar lo que originalmente eran colores reales. De este modo, cada píxel de la imagen tenía un valor de 0 a 255. Tras esto, se polarizaba la imagen, llevando cada valor de gris al extremo más cercano (de forma que los tonos entre 0 y 127 pasaban a ser todos 0, y los tonos entre 128 y 255, todos 255). Con ello, se conseguía una imagen pura en blanco y negro, sin ningún gris. El sistema entonces, realizaba un escaneo de la imagen, y redirigía el foco a la mayor concentración de blanco que se hallaba en la imagen, dando así lugar a un seguimiento real del haz de luz. 2.3.1.2 Desarrollo de Yubero Yubero llevó a cabo algunas mejoras en el sistema, principalmente la solución al problema que representaban las fuentes de luz externas en el entorno, que hacían que se bloquease el sistema. Al encontrarse la cámara con un centro de luz más grande que el haz que debía seguir, concentraba su atención en él, ignorando el haz de láser, y perdiendo por tanto la capacidad de seguimiento, como se puede ver en la figura 2.5 :



Figura 2.5 : Se pierde el objetivo en presencia de puntos de luz mayores

Este problema fue resuelto apoyándose en otros desarrollos ya usados en el campo de la videovigilancia. Dichos sistemas se basan en la sustracción de imágenes consecutivas, que fue lo que se hizo. Con el nuevo método de seguimiento, Seguimiento Láser II, se captaba una primera imagen, que era binarizada y polarizada, y se almacenaba en memoria. A continuación, se captaba una segunda imagen, que también era binarizada y polarizada. Entonces se procedía a hacer una sustracción píxel a píxel de las dos imágenes. Este proceso consiste en convertir el valor de los pixels a 0 o 1, puesto que ahora sólo quedaban los valores 0 y 255, después de la polarización. Tras reasignar valores a los pixels de las imágenes, se hacía una operación lógica X-OR, cogiendo un píxel de la primera imagen y el homólogo en la segunda. El resultado es que los centros de luz estáticos que aparecían en las dos imágenes se eliminaban con la operación X-OR, dejando en la imagen final sólo los puntos de luz que aparecen en la segunda imagen, y no aparecen en la primera. Esta condición únicamente la van a cumplir los puntos de luz que se han desplazado respecto de la primera imagen, dando lugar a un nuevo tipo de seguimiento, más por movimientos que por luminosidad. El nuevo proceso de seguimiento del láser se implementó en la aplicación, asignándole un nuevo nombre, Seguimiento láser II, y coexistiendo los dos tipos de seguimiento en la aplicación (Figura 2.6)

Figura 2.6.

En la imagen 2.7 se puede observar que con el nuevo método, el sistema ya no hace caso a las fuentes de luz fijas. También se ve que el puntero, cuando no se desplaza, tampoco aparece, perdiendo por tanto el objetivo, e iniciando el programa de búsqueda.



Figura 2.7 : Si el haz no se mueve, no se capta nada

Pero en el momento en el que el láser se empieza a mover, el sistema recupera el objetivo, y reinicia el seguimiento del haz de luz (Figura 2.8).

Figura 2.8 : El sistema reinicia el seguimiento si el puntero se mueve

2.3.2 Programas de control de la cámara 2.3.2.1 Programa CONTROL EVI-D31 de Yubero Como se mencionó, el programa de control de la cámara fue implementado por Alamo originalmente y, posteriormente, Yubero pasó a añadirle nuevas utilidades. Por lo tanto, se puede decir que realmente sólo hay un programa de control de la cámara, en el cual se integran tanto el seguimiento de catenarias y del haz de luz de Alamo, como el nuevo seguimiento del haz implementado, y el mecanismo de captura de imágenes de Yubero. En la Figura 2.9 se puede ver una imagen de esta aplicación, Control EVI-D31 :



Figura 2.9 :

2.3.2.2 El programa Autoevi de Yubero Este programa estaba destinado a dotar al sistema de visión de un primer proceso de autocalibración, aunque sin el movimiento lateral que el sistema necesitaría. La idea era mover el objetivo de la cámara tomando varias imágenes del mismo escenario inmóvil, y así poder realizar una valoración de las diferencias existentes en cada imagen. para ello, existían dos posibilidades distintas de movimiento (Figura 2.10) :

Figura 2.10 : dos posibilidades de movimiento

Por un lado, podía hacerse que la cámara siguiese una ruta trazada, en la cual tomaba un número de imágenes definido de antemano. En este caso, la secuencia de movimientos se puede comunicar a través de la ruta a un fichero de texto estándar, escrito según un código determinado que es entendible por el sistema. También era necesario comunicarle al programa el número de fotos que debía capturar durante el recorrido de la trayectoria marcada por el fichero. En la figura 2.11 se puede observar la aplicación Autoevi y la ventana de navegación que ofrece el programa al fichero de texto cuando se selecciona el movimiento de la misma según una ruta trazada :



Figura 2.11 : movimiento guiado por un archivo de texto.

Existe también la posibilidad de mover en un sentido, indicándole a la cámara cual era dicho sentido, y el número de imágenes a capturar. El diálogo que la aplicación lanza cuando se selecciona esta opción puede verse en la figura 2.12 :

Figura 2.12 : Movimiento según un sentido

En ambos casos, las imágenes se guardaban en un directorio determinado por defecto, con un nombre concreto, al cual se podía acceder llegado el caso para usar las imágenes en el proceso de autocalibración, si bien este proceso no llegó a implementarse en dicho proyecto y ha quedado un poco postergado con el cambio de dirección que se ha tomado en el presente año, más centrado en aunar capacidades de control de los dos dispositivos que en desarrollar las ya existentes sobre un dispositivo concreto.



2.4 Mejoras necesarias. Hasta ahora, se ha visto como estaban las cosas al comienzo del proyecto. Se han comentado las aplicaciones de control disponibles en aquel momento, con sus virtudes y defectos. El principal problema que presentaban era lo limitado de su rango de actuación. Sólo permitían el control de uno de los dispositivos del sistema, haciendo imposible ningún tipo de interacción entre ellos. Por tanto, el primer paso lógico que se debe dar en este proyecto es la unificación de funciones de control en un nuevo programa, que lo acerque un poco más al objetivo final. No obstante, se ha dejado un poco de lado en la descripción del sistema una parte fundamental del mismo, que es la que representa el vínculo de unión de todas sus partes. Hablamos del equipo donde se trabaja con los dispositivos, Heissenberg. Este equipo está integrado en el dominio del GVA, por lo que debe actualizarse al tiempo que lo hace la red. La llegada de nuevos proyectantes, este año más numerosos que en años anteriores, ha obligado a incorporar nuevos equipos al dominio. Esto hacía cada vez más difícil el mantenimiento de la red, por cuanto el sistema usado hasta entonces era Windows NT. Este sistema, que pasa por ser el más robusto de los de la familia Windows, es también el más complicado de mantener, por lo que se decidió migrar a un nuevo sistema operativo, obligando así a cambiar los componentes del dominio. 2.4.1 Implementación del carril lineal. Como se mencionó en los capítulos anteriores, el sistema de Percepción Artificial necesita de un carril lineal para poder realizar un proceso de autocalibración de la cámara Pan-Tilt. Este carril no existía en el momento en que se comenzó este proyecto, por lo que el primer paso inmediato es la implementación del propio carril. Las aplicaciones de control del mismo existentes hasta entonces podrían servir, puesto que lo que se diseñó en realidad era una copia a escala del carril que se desarrolló en el proyecto de Collado, con la diferencia de que, dadas las nuevas dimensiones del carril, se utilizó un nuevo sistema reductor. Ahora lo importante no era que el carril se moviese despacio, sino más bien al contrario, para poder asegurar una uniformidad en las imágenes del escenario que se iban a tomar. En el capítulo 3.1.7 de este proyecto se explicará detalladamente el proceso y los componentes necesarios para la puesta en marcha de este dispositivo, así como los principales problemas que surgieron. 2.4.2 Desarrollo de la nueva aplicación. Para poder controlar el carril y la cámara de manera conjunta, era necesario desarrollar una aplicación completamente nueva que intentase aunar las capacidades de control de las anteriores. Como punto de partida, se necesitaría que esta nueva aplicación controlase ambos dispositivos por separado, para, en un futuro, poder desarrollar un control simultaneo. El manejo individual de los dispositivos permite tener un punto de partida más asequible, puesto que se podría aprovechar parte del código generado por los anteriores proyectantes en el desarrollo de sus programas.



2.4.3 Instalación de Windows 2000. Como ya se mencionó, Heissenberg pertenece a una red de ordenadores con un dominio propio, el dominio GVA. Al estar en un dominio, todos los componentes del mismo tienen permisos de acceso a los equipos, lo que facilita el intercambio de información, así como la movilidad de los proyectantes. Inicialmente cada proyectante tiene asignado un ordenador para su trabajo, ya que cada proyecto necesita de programas concretos que a otros estudiantes no le son de utilidad. Pero sin embargo, hay programas que sí son de uso común, como pueden ser las herramientas de procesamiento de textos, necesarias para la elaboración de los informes que periódicamente todos los proyectantes deben presentar. La actualización de la red al nuevo sistema operativo Windows 2000, obligó a que también Heissenberg fuese actualizado para permitir un entorno común, en el que otros estudiantes pudiesen usar el equipo con una cierta familiaridad. Además, Windows 2000 presenta la ventaja de ser mucho más configurable y manejable que Windows NT 4.0, que era el sistema operativo instalado en Heissenberg anteriormente. Con el cambio al nuevo sistema operativo es necesario reinstalar todos los programas usados en el proyecto, así como los entornos de librerías que hacen que las aplicaciones implementadas puedan correr. También será necesario prestar especial atención a la automatización del servicio Tinyport, imprescindible para el control del carril lineal. Los detalles de este programa, así como los pormenores de su instalación en Heissenberg, se detallarán en el capítulo 3.1.8. 2.5 Futura evolución. Se describirán brevemente a continuación los pasos a seguir para la continuación del proyecto, las pistas básicas, para luego pasar a comentarlos con más detenimiento los capítulos de dedicados a ello. El primer objetivo sería claramente la implementación del carril lineal, así como la instalación de los programas y librerías necesarios para el manejo del mismo. El carril lineal en sí ya existía en el momento en el que se comenzó el proyecto. No estaba, sin embargo, puesto en funcionamiento, ya que no se había implementado la plataforma sobre la que debía fijarse la cámara. Tampoco se había implementado el sistema eléctrico que controla los puntos limites del movimiento de la plataforma. Ese es, pues, el primer trabajo que se tenía que acometer. Una vez cumplido este paso, deben instalarse los programas que controlan el sistema, principalmente el servicio Tinyport, imprescindible para poder realizar el envío y adquisición de datos del movimiento del motor en tiempo real. Una vez hecho esto, cualquier programa de los que controlaban el carril original, debería controlar el nuevo sistema, permitiendo empezar a trabajar con el carril. El siguiente paso, sería la instalación del nuevo sistema operativo. para ello, sería conveniente hacer una copia de seguridad de todos los datos importantes almacenados en el ordenador (Programas de otros proyectantes, información relativa al proyecto, documentos, informes y programas de uso común), de forma que no se pierda información útil para el Grupo. Se aprovechará este punto para formatear los discos duros del



ordenador Heissenberg y poder trabajar así en un sistema completamente estable y mucho más rápido. Esto se hace necesario, puesto que los muchos estudiantes que han manejado el ordenador, así como la cantidad de programas que se instalaron para hacer pruebas a lo largo de los cursos, hacen que el sistema se vaya ralentizando. A continuación, se debe llevar a cabo la implementación de la nueva aplicación. para ello, como se comentó, se partirá de los modelos disponibles, como son las aplicaciones de los años anteriores, dedicadas al control de los dispositivitos individuales. También es importante platearse qué funciones va a tener la aplicación desarrollada, puesto que cuantas más posibilidades de manejo ofrezca, más complicado es su uso, al necesitar de la introducción de comandos. Planteados todos estos puntos, se llegó a la conclusión de que lo mejor sería poder contar con resultados inmediatos, para así saber si la programación del manejo de la aplicación es correcta. Se implementará por tanto una primera aplicación muy básica, sólo con las posibilidades de mover la cámara y el carril a posiciones concretas y de hacer autozoom y autoenfoque con la cámara. Habría también la posibilidad de llevar al carril o a la cámara a los puntos de inicio, además de disponer el programa de un comando de ayuda, donde explicaría todas los comandos de movimiento disponibles. Con esta primera aplicación el movimiento de los dispositivos está todavía separado, pero ya se pueden controlar los dos desde un mismo programa, lo cual sin duda ya es una ventaja. Se procede entonces a la realización de un modelo, antes de acometer el proceso de programación en sí. Se debe hacer un estudio previo a la programación, donde modelizar el sistema. para ello, se usarán los procedimientos de UML y se codificará la aplicación sobre la base de estos planteamientos. Esta modelización ayudará a plantear una aplicación más modular, con mayor independencia entre sus partes, lo que ayudará a aprovechar el código en futuras mejoras de próximos proyectantes. Una vez modelizado el sistema, vendría la programación. En un principio, tenía que ser en modo grafico, para que tuviese un manejo más intuitivo. Pero el problema es que para empezar desde cero, la programación de aplicaciones en modo grafico es más complicada que en modo consola. Así que se decidió hacer primero la aplicación en modo consola, para, más adelante, pasarla a modo grafico, lo que ayudará a tener resultados mucho más inmediatos. Todo este proceso de creación se explicará detalladamente a lo largo del proyecto.


Capítulo 3. Descripción del sistema de Percepción Artificial. A continuación se explicarán minuciosamente los componentes del sistema, sus funcionalidades, características técnicas, etc. El objetivo es permitir ofrecer una visión general que permita a una persona ajena al proyecto entender el funcionamiento del mismo. Esto es muy importante para el Departamento, puesto que los nuevos proyectantes que se van incorporando al mismo, y que tienen que continuar con los proyectos ya empezados, no disponen de mucho tiempo para absorber los conocimientos necesarios para ponerse en marcha. Sin estas pequeñas guías, el proceso de incorporación sería indudablemente mucho más lento y traumático. En la figura 3.1, podemos observar el aspecto general del sistema, con todas las partes que lo componen. Aparentemente, puede parecer que hay más partes que el carril y la cámara comentados en los capítulos precedentes, pero es una impresión errónea, ya que las partes no mencionadas anteriormente únicamente hacen una labor de control y estabilización de la alimentación del motor, como se verá a continuación.

Figura 3.1 : El sistema de Percepción Artificial.


Descripción del sistema Iván Ruiz Tejedor de Percepción Artificial.

En la figura puede verse asimismo como la cámara está montada y fija sobre la plataforma móvil del carril, y que se desplaza mediante el movimiento que el motor comunica a una cinta dentada con la que está engranada. Para conseguir este movimiento, se necesitan los tres dispositivos de alimentación antes mencionados. Por una lado, una fuente de alimentación en continua, que permita alimentar el motor con su tensión nominal, como se verá más adelante. Por otro lado, una tarjeta de potencia, que permite que la alimentación de la fuente sea controlada y estable y, al tiempo, se encarga del control de posición de la plataforma a través de un circuito eléctrico. También se necesitarán ciertas tarjetas pinchadas en el ordenador, Heissenberg, que sirven de interfaz para poder comunicar tanto la cámara como el carril con el programa que los debe controlar. Sin ellas, no sería posible dar entrada al ordenador a las señales enviadas por los dispositivos. Y por supuesto, no hay que olvidar a los actores principales del sistema, que son la cámara Autoevi y el carril lineal eléctrico. En los siguientes apartados se detallarán las características de todos los componentes, así como de las conexiones a implementar para el correcto funcionamiento del sistema. Primeramente, se comentarán los componentes del carril, las conexiones necesarias y las interacciones entre los distintos dispositivos y los programas necesarios para poder controlar el conjunto. A continuación, se mostrará la cámara, sus características técnicas, los dispositivos adicionales necesarios y, de nuevo, los programas necesarios para el manejo de la cámara. 3.1 Descripción del carril lineal Hoy en día los motores eléctricos han demostrado ser una solución incontestable para muchas de las aplicaciones que se usan en la vida cotidiana. Desde los aparatos domésticos hasta los sistemas de transportes, están presentes en casi todo lo que se maneja en el día a día. Este uso de los motores no sería posible sin la gran capacidad de control que sobre ellos se ha desarrollado. Desde motores en los que se controla la alimentación que reciben con un sencillo interruptor, hasta los grandes sistemas eléctricos de, por ejemplo, una locomotora de tren, donde el control, además de suave, debe ser preciso, con todos los inconvenientes que eso representa. El control de motores, por tanto, se ha convertido en una herramienta tan habitual como variada, puesto que cada necesidad precisa de soluciones de control muy concretas. Por ello, en este capitulo, se intentará dar una visión completa al complejo tema del control de motores, así como de las posibilidades comerciales que existen en el mercado, para luego ahondar en las opciones escogidas. Con estos conocimientos, se espera que el lector obtenga la capacidad de hacer funcionar el sistema obtenido, sin correr el riesgo de malograrlo en el aprendizaje. Básicamente, la industria actual se basa en utilizar el movimiento de una fuente para transformar las propiedades de una determinada materia prima, dando lugar a un producto nuevo. Este movimiento se obtiene del uso de los motores, que pueden ser clasificados en tres grandes grupos :


Iván Ruiz Tejedor Descripción del sistema de Percepción Artificial.

• De combustión : que transforman energía química en movimiento. • Hidráulicos : transforman la energía potencial producida por la gravedad en un

movimiento aprovechable en la industria.

• Eléctricos : que, a partir de energía eléctrica, permiten mover objetos. El uso de unos motores u otros depende en gran medida del fin al que está destinado, puesto que las características entre unos y otros son muy diferentes, por lo que las ventajas que presentan en un caso determinado varían ampliamente. Mientras que los motores hidráulicos requieren mucho espacio y un mantenimiento relativamente habitual, los motores eléctricos pueden llegar a tamaños sorprendentes y ofrecer grandes prestaciones sin casi ninguna revisión. Pero también tienen el inconveniente de presentar una relación potencia / tamaño mucho menor que los primeros. En el caso que nos ocupa, además del problema del tamaño, necesariamente no muy grande, existe un problema de precisión, ya que el sistema debe acometer procesos de calculo de distancias a partir de imágenes, donde la precisión debe ser tenida en cuenta. El motor eléctrico ofrece tamaños aceptables para las relaciones de tracción que se van a usar, con la ventaja de la gran capacidad de control que tienen. Es por eso por lo que en el proyecto, se opto por un motor eléctrico. 3.1.1 Tipos de motores. Ya se ha mencionado que un motor eléctrico es un dispositivo capaza de transformar la energía eléctrica en movimiento. En función del tipo de corriente que se le suministra al motor, se pueden clasificar en dos grandes grupos : • Motores de corriente continua (CC) : la tensión de alimentación del motor no varia.

Estos son los motores que se suelen usar cuando la aplicación requieres de variaciones de velocidad.

• Motores de corriente alterna (CA) : están alimentados por una tensión que varia con una

determinada frecuencia. Se dividen a su vez en dos grandes grupos, los motores de inducción y los motores síncronos.

Cada tipo de motor tiene ventajas e inconvenientes según el uso al que va orientado, pero en general, los motores de corriente continua y los motores paso a paso presentan unas posibilidades de control y regulación por encima de las de los demás, resultando en los primeros mucho más sencillo saber en que posición exacta se encuentra el eje de giro del motor y sabiendo que los segundos pueden girar ángulos concretos en función de los impulsos de alimentación que se suministran al mismo. En este proyecto, para el movimiento del carril, se optó por un motor de corriente continua, por diversas razones que no vienen al caso. Este tipo de motor tiene una particularidad, y es que no es capaz de controlar el giro en lazo abierto, por lo que será necesario instalar también un controlador en lazo cerrado, según el esquema que se ve en la figura 3.2 :



Figura 3.2 : Control del motor en lazo cerrado

En el motor elegido, la relación que se establece entre la señal aplicada y el movimiento producido (Es decir, la posición final obtenida), no es fiable, por lo que se debe recurrir al uso de un controlador en lazo cerrado. Con este sistema, lo que se hace es realimentar la velocidad del motor, compuesta con una señal de control, para obtener una función de error en la posición que el controlador trata de minimizar. Este control de la posición final hace que, aunque el sistema se vea afectado por ruidos eléctricos, las prestaciones no se vean disminuidas sensiblemente. El inconveniente que presenta es que el sistema requiere de una mayor inversión en hardware, puesto que hay que incorporar al sistema un detector de posición del eje para controlar la posición final del movimiento. Existen en el mercado numerosos tipos y modelos de detectores de posición (Resistivos, magnéticos, capacitivos, etc.) Sin embargo, los de tipo óptico son los más prácticos y sencillos de usar. Su funcionamiento se basa en un emisor de luz y un receptor, entre los que gira un disco acoplado al motor, y que tiene zonas opacas y zonas transparentes. Cuando el motor gira el disco se mueve también, cortando el haz de luz que va del emisor al receptor cuando el rayo pasa por una zona opaca. Esto provoca una serie de impulsos eléctricos que permiten averiguar cual es el ángulo que se ha girado el eje y el sentido en el que se ha hecho. Mediante este sistema, y en función del número de ranuras que tenga el disco, se puede hacer una detección del movimiento muy aceptable. 3.1.1.1 Control de motores. El movimiento que genera un motor de corriente continua es directamente proporcional a la tensión que se le suministra y al flujo que dicha tensión genera en el inducido del mismo, por lo que para el control de la velocidad se recurre a la manipulación de estos dos factores, según lo requiera la aplicación a la que va destinada el motor. Dependiendo de si lo que se quiere mantener constante en el movimiento (el par o la potencia absorbida), el control del motor debe manipular uno de los factores o el otro : • Control por inducido : controla la tensión de entrada en el inducido del motor,

manteniendo constante la excitación en el campo inductor. Con ello se mantiene el par del motor constante aunque varíe la velocidad de desplazamiento (Ui≠cte; Φ=cte). La actuación sobre el motor se puede ver en el esquema siguiente (Figura 3.3), donde :

Pm = Kp · ii(t); y Ui = Ri · ii(t) + Li · [dii(t) / dt] + Um(t)



Figura 3.3 : Control por inducido

I=Cte.

Ui(t)

Ii(t)

B

Li Ri • Control por excitación : permite mantener constante la potencia que el motor absorbe en

el movimiento, permaneciendo constante la excitación del inducido y actuando sobre la corriente de excitación del campo inductor. La actuación sobre el motor se puede ver en la figura 3.4, donde :

Pm(t) = Kp · ie(t); y Ue(t) = Re · ie(t) + Le [die(t) / dt]

B

ie(t)

Ue(t)

Ri.

Li

ii = Cte

Figura 3.4 : Control por excitación.

3.1.1.2 Métodos de control de potencia. Si lo que se quiere, por otro lado, es controlar la potencia que absorbe el motor, hay tres métodos para hacerlo : • Rectificación controlada por silicio : o también SCR (Del ingles Silicon Controlled

Rectifier). Es el método más usado en corriente alterna, basándose en el uso de tiristores (componentes semiconductores con dos estados estables, cuyo funcionamiento se basa en la realimentación regenerativa de la estructura PNPN interna)

• Modulación de la frecuencia del pulso : o PFM (Del ingles Pulse Frecuency Modulation),

también es un método de control en corriente alterna. Se basa en que :

“El valor medio de una señal periódica es igual a la integral entre cero y el periodo de la función de la señal respecto al tiempo, dividido todo ello por el valor del periodo”



Y según esto, en el caso de una señal lógica, el periodo puede hacerse constante, siendo la función discontinua, definida a trozos. Se obtiene entonces que el valor medio de esa señal en el periodo fijado es el valor de la señal en su estado alto por el tiempo que la señal está en estado alto en ese periodo, más el valor de la señal en estado bajo por el tiempo que está la señal en estado bajo y dividido todo ello por el periodo considerado.

TOTAL

LL

TOTAL

HH

TTV

TTV

y⋅

+⋅

=

Por lo tanto, si se mantiene constante el ancho del pulso y se va variando la frecuencia con la que se repite el pulso, se varía la tensión media que se entrega al motor, resultando de ello una variación de la velocidad. En la figura 3.5 se puede ver un esquema del planteamiento.

Figura 3.5 : Control PFM.

• Modulación del ancho del pulso : también conocido por las siglas PWM (Del ingles

Pulse Width Modulation), es un método válido para corriente continua. Se basa, al igual que el anterior, en el cálculo del valor medio de la función, salvo que ahora lo que se aplica es una variación en el tiempo que la señal está en valor alto a lo largo del periodo considerado, como se ve en la figura 3.6. En el caso de este proyecto, y dado que el motor usado es de corriente continua, se empleará este método. También hay que señalar que este método requiere de mucha menos implementación de hardware que los anteriores

Figura 3.6 : Control PWM.



3.1.1.3 Métodos de control de velocidad. Para poder controlar con efectividad el motor, controlar la potencia no sería suficiente, puesto que se debe mover con una velocidad determinada en cada instante del recorrido. para ello, existen dos implementaciones industriales para el control de la velocidad de giro del motor de corriente continua : • El puente de transistores en H : su nombre viene de que el circuito con el que se

implementa tiene una forma parecida a la letra H, como se aprecia en la figura 3.7. Con este puente de transistores se puede controlar la tensión de alimentación del motor, consiguiendo que gire en cada instante a la velocidad deseada. Cuando las señales de control se lanzan en las ramas opuestas del puente (por ejemplo, B1 y B2), la corriente en un sentido es máxima. Si las ramas que se activan son las contrarias (es decir, A1 y A2), entonces la corriente también es máxima, pero de sentido contrario al anterior. Cuando ninguna de las ramas está abierta, no circulará corriente y el motor se detiene.

Figura 3.7 : Puente de transistores en H

Las señales de control en el puente son de tipo TTL, mientras que las líneas de alimentación de los transistores del puente estarían alimentadas con el voltaje máximo del motor, de manera que cuando el puente se abre y pasa corriente en uno u otro sentido, la tensión de alimentación que recibe el motor es su tensión nominal, por lo que no sufre por tener que mover el motor con menos tensión de la necesaria, con el riesgo de quemarlo que ello conlleva.

El motor, por tanto, en esta situación tiene tres posibilidades de alimentación : A1=1, A2=1, B1=0, B2=0, nos daría el sentido de giro 1. A1=0, A2=0, B1=1, B2=1, nos daría el sentido de giro 2. Y A1=0, A2=0, B1=0, B2=0, hacen que el motor no se mueva, por no circular corriente. Combinando esta técnica con el control PWM, se obtiene un método de control de la alimentación de l motor, por hardware, lo que nos permite controlar la velocidad de manera segura y efectiva. Esta ventaja, junto con la necesidad de una sola fuente, son las que decidieron que se usase este método en el presente proyecto.



• Configuración en T : es el otro gran método, que aunque ofrece mayor economía de

hardware, necesita del uso de dos fuentes de alimentación en continua. Puesto que no se usará en este proyecto, no se profundizará en su implementación.

3.1.2 El motor Maxon-698. Es el motor al cual se recurrió en este proyecto para mover la plataforma del carril lineal. Se trata de un pequeño motor de corriente continua, de 15 watios de potencia, y que es capaz de desplazar la plataforma del carril hasta una velocidad aproximada de 500 r.p.m. En la figura 3.8 puede verse un esquema del motor y a continuación se detallarán sus características técnicas :

Figura 3.8 : Diagrama del motor Maxon-698.

- Potencia nominal: 15 W - Voltaje nominal: 24 V - Velocidad en vacío: 5750 r.p.m.

- Máximo par de inicio: 119 mN·m

- Corriente sin carga: 26.3 mA

- Corriente de inicio: 3020 mA

- Resistencia de inducido: 7.94 W

- Gradiente velocidad / par: 49 rpm/mN·m

- Velocidad máxima permitida: 9200 r.p.m.

- Corriente continua máxima: 786 mA



- Par continuo máximo: 30.9 mNm

- Máxima potencia de salida con la tensión nominal: 17,500 W

- Máximo rendimiento: 81.5 %

- Constante de par: 39.3 mN·m/A

- Constante de velocidad: 243 rpm/V

- Constante de tiempo mecánica: 13.7 ms

- Inercia del rotor: 26.6 g·cm2

- Inductancia de inducido: 1.54 mH

- Resistencia térmica entre carcasa y ambiente: 12.50 K/W

- Resistencia térmica entre rotor y carcasa: 1.90 K/W

Además, el motor incorpora un encoder óptico acoplable (Ver figura 3.9), a 5 V, que es plenamente compatible con las señales TTL. Este encoder es capaz de realizar hasta 500 cuentas por giro y será el encargado de realimentar la señal de posición para el control del motor.

Figura 3.9 : Acoplador óptico del Maxon-698.

En la siguiente figura (Figura 3.10), puede verse una vista general del sistema, con el motor Maxon, con el encoder acoplado y colocado en el carril lineal.

Figura 3.10 : Acoplamiento del motor y el encoder.



3.1.3 El controlador digital SMCC-01. Para poder controlar el motor del carril lineal, se necesita una serie de circuitos, reunidos en este controlador SMCC-01. Con él se pueden controlar hasta tres motores de corriente continua simultáneamente, sin necesidad de ningún otro elemento externo. El dispositivo está formado por dos tarjetas, una para el control de potencia mediante PWM y otra que actúa de interfaz entre el sistema y el PC. El nexo de unión entre ambas tarjetas consiste en un cable plano paralelo, con conectores de 37 pines en los extremos (DB37). Adicionalmente, el SMCC-01 es capaz de manejar un cuarto eje, aunque éste ya sin control de ningún tipo. Sus partes más importantes son : - 1 chip 82C55A que se ocupa de gestionar las posibles entradas / salidas digitales para la

relación con el exterior (Figura 3.11.A). - 3 chips LM629, encargados del control de los motores CC (Figura 3.11.B). - 3 puentes de potencia en H implementados con relés, uno para cada motor.

B

A

Figura 3.11. 3.1.3.1 Componente de control. La tarjeta de control representa el punto de entrada de la información desde la tarjeta de potencia al ordenador. Se trata de una tarjeta, con conexión ISA, configurada para ocupar la dirección de memoria 300 mediante unos microinterruptores. En ella se encuentran los chips LM629 y 82C55A, que se detallarán más adelante, dada su importancia en el sistema. También se encuentra en la tarjeta un circuito integrado, diseñado específicamente para el control de motores de corriente continua, con o sin escobillas. Este microcontrolador está encargado de la descodificación de la posición del motor, ejecutar el algoritmo del filtro PID, de la generación de trayectorias viables para el movimiento y de proporcionar al sistema la señal de control y de sentido de giro, para poder conectar directamente un amplificador PWM. Con ello se libera al ordenador de la carga de estas funciones, lo que deja más recursos libres al sistema, permitiendo un mejor rendimiento del mismo en otras tareas. En la figura 3.12 puede verse una imagen de este componente :



Figura 3.12 : Tarjeta de control del SMCC-01.

Las características principales de esta placa son :

− Compatible con bus ISA. − Algoritmo de control PID digital. − Control de velocidad, posición y aceleración. − Generación de perfiles de velocidad y posición. − Entradas / salidas digitales opto-aisladas. − Entrada para codificador óptico incremental. − Salida PWM y sentido de giro, para manejar un puente en H.

3.1.3.2 Componente de potencia. Con la tarjeta de potencia del dispositivo podemos realizar el control PWM, y, como punto más relevante, en ella se sitúan los puentes en H que permiten controlar la velocidad de los motores. También lleva un frontal que sirve de interfaz para la comunicación con la tarjeta de control, la alimentación del sistema y la salida para los tres motores, como se puede apreciar en la siguiente figura (Figura 3.13)



Figura 3.13 : Tarjeta de potencia del SMCC-01.

Las principales características técnicas de esta tarjeta son :

- Capacidad de manejar hasta 3 motores de corriente continua simultáneamente.

- Alimentación de 12 a 55V. de corriente continua. - Entradas PWM. - Potencia continua 250 W por motor. Potencia de pico: 1.100 W. - Dos niveles de protección de corriente. - Puente en H completo implementado con relés, para un cuarto eje no

controlado. - Consumo desde fuente principal: 5 W. - Tiempo de sobrecarga: 10 s, pasado el umbral de potencia continua. - Frecuencia máxima de PWM: 30 KHz. - Ancho del pulso mínimo: 4 µs.



3.1.4 El integrado LM629. Este circuito es un controlador de movimiento de precisión, muy útil en una gran variedad de usos con motores de corriente continua, tanto si se trata de motores con escobillas como sin ellas. También es usado en implementaciones de servomecanismos cuya realimentación de posición sea una señal incremental en cuadratura. 3.1.4.1 Especificaciones técnicas. Para construir un servosistema se requiere un motor CC (con un engranaje reductor, si fuera el caso; en este proyecto concreto sí que se usará), un encoder incremental de posición, un convertidor digital analógico (DAC), una fuente de alimentación de corriente continua, y el integrado LM629. Este chip, en su interior, lleva implementados un decodificador de posición, un filtro digital PID y un generador de trayectorias. El sistema está diseñado para conectarse directamente a la entrada de un amplificador PWM y envía una señal de pulso de 7 bits, más un octavo, que corresponde al signo del movimiento (Por lo que se deben descodificar 2 señales analógicas). La frecuencia máxima a la que puede trabajar es de 3,9063 KHz., para una frecuencia de 8 MHz. Sus principales características son :

- 3 registros de 32 bits para la posición, la velocidad y la aceleración. - Un filtro digital PID programable. - Una señal de salida PWM de 8 bits. - Un generador interno de perfiles de velocidad trapezoidales. - La velocidad, la posición y los parámetros del filtro pueden ser cambiados

durante el movimiento. - Distintos modos de operación en cuanto a posición y a velocidad. - Interrupciones programables en tiempo real. - Capacidad de gestión de señales incrementales en cuadratura.

Para construir un servosistema con el integrado LM629, se debe usar un diagrama de bloques como el de la figura 3.14 :



Figura 3.14 : Diagrama de bloques de un servosistema.

Según este diagrama, el procesador se comunica con el LM629 a través de un puerto de entrada / salida, para facilitar la programación del perfil trapezoidal de velocidad y del filtro PID. para iniciar el movimiento, el procesador central carga los valores de aceleración, velocidad y posición deseados en el generador de trayectorias del LM629. En cada período de muestreo, estos valores son usados para calcular la nueva posición deseada, a la que se le restaría la posición real del eje, obtenida por el codificador óptico incremental y el decodificador de posición. Así se origina la señal de error, que es la que entrará al filtro PID. El convertidor digital-analógico convierte entonces la señal producida a otra nueva, que ya es aplicable al motor. Finalmente, se decodifica de nuevo la posición y se genera otro perfil de velocidad. 3.1.4.2 Generación de trayectorias. Incluido en el integrado LM629, el generador de perfiles trapezoidales de velocidad manda la posición del motor frente al tiempo (es decir, la evolución de la velocidad). El procesador debe entonces transmitir la información sobre la aceleración, la máxima velocidad y la posición final que debe alcanzarse. El LM629 utilizará esta información para mover el motor, según los datos enviados. Primeramente la velocidad se incrementa en función de la aceleración consignada, hasta que se alcanza la velocidad máxima especificada en el registro correspondiente. Posteriormente, se mantiene esta velocidad constante, hasta que comienza una desaceleración de igual magnitud que la aceleración inicial. La posición final marcada, a la cual se desea y se debe llegar después del movimiento, es la integral del perfil trapezoidal de velocidad generado. En la figura 3.15 se puede ver la figura típica que se genera cuando se calcula un perfil trapeziodal. Si hay perturbaciones durante la aceleración o el tramo de velocidad constante, se prolonga la posición para que la velocidad media se mantenga constante. Esto se debe a que es la principal variable de cálculo para la obtención de la posición final. Prácticamente en todos los perfiles hay un error de posición o de velocidad, que aunque es mínimo, sí que debe ser tenido en cuenta (en cualquier caso, el regulador PID se encargará de minimizar este error).



Figura 3.15 : Perfil trapezoidal de velocidad.

3.1.4.3 Seguimiento de la posición. La realimentación de la posición es imprescindible para el control del motor, como ya se vio anteriormente. Esta realimentación la realiza en encoder incremental, conectado al motor y que permite la comunicación entre éste y el integrado LM629, que contiene una interfaz para codificadores de posición ópticos incrementales. Para su funcionamiento, se decodifican dos señales de salida en cuadratura, proporcionando información sobre la posición y la dirección del movimiento. Opcionalmente, puede también usarse una señal de posición de índice, para capturar la posición del motor una vez por revolución. Cada uno de los cuatro estados de las señales de posición en cuadratura es decodificado en el LM629, cuadruplicando la resolución sobre el número de líneas del encoder. Con esto se puede aumentar un codificador con N líneas para ser decodificado como 4N cuentas de posición. En la Figura 3.16 se puede ver la dirección tanto positiva como negativa de las cuentas realizadas por el decodificador de posición. Las señales A, B, e INDEX, procedentes del encoder, son la entrada al decodificador. Este determina si el motor se movió hacia la izquierda, hacia la derecha o permaneció parado, almacenando la posición del motor en un contador. Además, una vez por revolución, cuando todas las líneas del encoder están simultáneamente a nivel bajo, se captura la posición actual del motor en un registro para el índice, como puede observarse igualmente en la figura.

Figura 3.16 : Cuentas del encoder.



El máximo rango de captura de la posición se determina por el mínimo número de ciclos de reloj que se necesitan para decodificar cada estado del encoder. Como se observa en la figura, este mínimo es de 8 ciclos, lo que supone una limitación de la velocidad máxima que puede alcanzar el eje del motor, puesto que no debe superar a la capacidad de captura del decodificador. Sin embargo, a efectos prácticos, esto no supone ninguna limitación, pues la velocidad máxima impuesta es de 30000 r.p.m. para el LM629 a 8MHz, considerando un codificador óptico de 500 líneas por vuelta. 3.1.4.4 El regulador PID. El integrado LM629 usa también un filtro PID para compensar el lazo de control. La implementación de este filtro es la siguiente :

∑=

−−++=n

inndninp eeKeKeKnU

01'' )·(··)(

Donde la señal aplicada al motor es proporcional a la señal de error en posición en el instante n, más la integral del error, más la derivada del error, sabiendo que :

• U(n) : es la señal de control aplicada al motor en el instante n. • en : es el error de posición en el instante n.

• en’ : es el error de posición en el muestreo derivativo de n (n’).

• en’-1 : es el error de posición en el muestreo derivativo anterior a n’.

El primer término, Kp·en, es el llamado término proporcional, y transmite al motor una fuerza ajustada a la señal de error según la Ley de Hooke. El segundo término, Ki·Σen es el término integral, y permite al motor incrementar su velocidad con el tiempo, además de asegurar que el error estático de posición es cero. El tercer término, Kd·(en’-en’-1) es el término derivativo, y suministra una señal proporcional para mejorar el error de posición. En este caso, el periodo de muestreo derivativo se debe escoger como múltiplo del periodo de muestreo del LM629 (que va desde 1 hasta 256). En la operación, el algoritmo del filtro recibe una señal de error de 16 bits, proveniente de la resta entre la señal del generador de trayectorias y la realimentación de posición. La señal se satura a los 16 bits para impedir un comportamiento imprevisible del sistema. Esta señal de error multiplicada por el coeficiente proporcional, Kp, se suma en cada muestreo a los errores acumulados anteriormente en forma de suma integral (Ki), para conseguir una señal de 24 bits (aunque sólo los 16 más significativos serán usados posteriormente para multiplicarlos con el coeficiente derivativo Kd). Los 16 bits menos significativos de cada uno de los tres productos (puesto que cada producto es un registro de 32 bits), se suman para producir la señal de control. De estos 16 bits, los 8 más significativos forman la salida, que tras ser debidamente tratada,



decodificada y amplificada por la etapa de potencia, alimentará al motor para conducirlo a la posición designada. 3.1.4.5 Alimentación del motor con una señal PWM La salida del integrado LM629 es una señal del tipo PWM, explicada anteriormente y proporciona las señales de amplitud y signo necesarias para alimentar al amplificador. Son éstas dos señales independientes, la señal de amplitud y la señal de signo, las que determinan la tensión y la polaridad en la alimentación del motor, respectivamente. Por una lado, la señal de amplitud consiste en un tren de pulsos, a una frecuencia constante (en el caso de este proyecto, 512/frecuencia), cuya duración va en función de la señal de control obtenida del PID. Cuanto mayor sea ésta, mayor será el llamado factor de servicio o duty-cycle y, por lo tanto, mayor será la tensión que reciba el motor. En la figura 3.17 puede verse una representación de la salida PWM, generada por el LM629 :

Figura 3.17.

El rango de a (siendo a = duración del pulso, dividido entre el período de la señal) estará entre 0/128 (motor parado), 127/128 (mayor tensión con polaridad positiva) ó 128/128 (tensión continua, polaridad negativa). Se ve entonces que hay cuatro períodos PWM en un intervalo de muestreo del LM629 y, por tanto, para un LM629 con un reloj de 8 MHz se incrementa el rango de salida desde 3,9 KHz a una frecuencia de conmutación del puente en H de 15,6 KHz. A modo de resumen, en la figura siguiente (figura 3.18), puede verse una representación del funcionamiento del chip LM629 :



Figura 3.18 : Funcionamiento del LM629.

3.1.5 El filtro PID. El uso de controladores digitales en sistemas de automatización y control es una practica que se ha visto incrementada en los últimos años, siendo el método más fiable, económico y seguro de alcanzar el rendimiento óptimo de un sistema. La tendencia actual de hacer un control digital de los sistemas dinámicos se debe, principalmente, a la economía que ofrecen las computadoras digitales, con precios cada vez menores y que permiten disfrutar de la ventaja que supone el pasar de trabajar con señales discretas en lugar de señales en tiempo continuo. El controlador, por tanto, se revela como un instrumento capaz de sustituir al operador humano en su tarea de mantener una determinada variable del proceso en torno a un valor deseado, mediante actuaciones sobre otra variable denominada “manipulada”, según el esquema de la figura 3.19 :

Figura 3.19 : Funcionamiento de un controlador.



Los controladores normalmente permiten la operación en modo “manual” dejando al operador exterior elegir el valor de la variable manipulada. También pueden operar en modo automático, efectuando modificaciones sobre la variable manipulada de acuerdo con unas leyes de actuación. En el caso concreto que nos interesa para nuestro sistema, estas leyes serían de un tipo particular , llamado PID. La amplitud de uso que este tipo de controlador ha obtenido se puede resumir en los siguientes puntos : · Son muy simples porque su funcionamiento se puede implementar con elementos poco

sofisticados: puramente mecánicos, neumáticos o electrónicos. · Se encuentran sumamente extendidos en el campo del control de procesos. Los más primitivos controladores eran PID y aún ahora siguen implantándose masivamente. · A pesar de ser simples, su eficacia está fuera de duda y, de hecho, en la actualidad son muy utilizados, aun disponiendo de herramientas para realizar algoritmos de control mucho más sofisticados. Sólo en casos muy puntuales, en los que el control PID es insuficiente, se recurre a realizar un análisis más profundo y a la obtención de algoritmos más adecuados a la dinámica del proceso que se pretende controlar. 3.1.5.1 Funcionamiento del regulador PID. El modo de funcionamiento de un controlador PID se puede descomponer en tres actuaciones básicas, de las cuales viene el nombre del regulador, y que son la Acción Proporcional (P), la Acción Integral (I) y la Acción Derivativa (D). A continuación se describirá cada una de ellas : • Acción Proporcional : se denomina así a una actuación sobre la variable manipulada que

es proporcional a la desviación o error de la variable a controlar desde su consigna. Cada incremento de desviación tiene como respuesta un incremento de actuación proporcional al primero. La intensidad de la acción proporcional está determinada por el parámetro denominado “Ganancia”. Esta actuación se podría resumir en la siguiente fórmula :

Incremento de desviación · Ganancia = Incremento de actuación.

Cuando la respuesta a una desviación de un 1% es una actuación de un 3%, se dice que el controlador tiene una ganancia de 3. El valor de la ganancia de un controlador depende de las escalas que se elijan para la variable a controlar y para la variable manipulable. Por ejemplo, si un proceso necesita, para compensar el error de 1 grado de su temperatura, que una válvula se mueva un 1%, su controlador debería estar ajustado con una ganancia de un 1, si la escala fuese 100 grados, o con una ganancia de 10 si su escala fuese 1000 grados. La intensidad de la acción proporcional también se cuantifica con el parámetro denominado “Banda proporcional”, que es la banda de desviación que supone una actuación de un 100%. Por tanto, una banda proporcional de un 25% es equivalente a una ganancia de 4. Como los controladores proporcionales transmiten los errores permanentes, normalmente actúan junto con la acción integral.



• Acción integral : la actuación integral del controlador es proporcional a la desviación de

la variable a controlar y al tiempo que se mantiene esta desviación. Se trata de una integración en el tiempo. El parámetro que cuantifica la acción integral se expresa en repeticiones por unidad de tiempo, que es el tiempo que tarda la acción integral en repetir la actuación correspondiente a la acción proporcional, en el caso de que se mantenga el error constante. También se utiliza el parámetro inverso que le corresponden a las unidades recíprocas, esto es, el número de unidades de tiempo por repetición. La acción integral no permite errores permanentes y ante ellos provoca cambios continuos en la variable manipulada.

• Acción derivativa : es proporcional al cambio de pendiente de la variable a controlar (o,

lo que es lo mismo, de la desviación). El parámetro que cuantifica la acción derivativa se expresa en unidades de tiempo y su cantidad se corresponde al adelanto de la acción proporcional que se produce por la acción derivada. Por ejemplo si la ganancia es 3, el parámetro derivativo es 2 segundos, se produce un cambio de pendiente de un 1 % cada segundo y la acción derivativa provocará una actuación de un 6%.

3.1.5.2 Aplicación al presente sistema. Existen dos métodos básicos para el diseño de reguladores digitales : Método continuo: se diseña el regulador con técnicas de control continuo (R(s)) y luego se discretiza.

Diseño digital directo: se discretiza el modelo de planta y se realiza el diseño del regulador mediante técnicas discretas.

En el caso del motor de corriente continua del presente proyecto se recurrió al uso del segundo método, discretizando el modelo del motor, con la finalidad de obtener los coeficientes Kp, Ki y Kd, que permitan la optimización del proceso. A continuación se detallarán ambos métodos. 3.1.5.3 El método continuo. En un regulador puede ser discretizado mediante el reemplazo de la derivación por una diferencia respecto al punto de tiempo anterior y la integración por un sumatorio, con lo que queda :

)(11−−⋅≈ kk ee

Tdtde

∫ ∑=

≈K

iieTdte

0··



Siendo T el periodo de muestreo de la señal de error. Así, teniendo en cuenta el ciclo de control en el programa, se podría escribir el regulador PID digital del siguiente modo, tal y como se vio para el LM629 :

−++= ∑

=−

K

ikk

Di

ikk ee

TTe

TTeU

01)(·

Para conseguir los valores ideales de los coeficientes antes mencionados, Ki,, Kp y Kd, se deberán seguir una serie de pasos : 1) Calculo de un regulador PID continuo, mediante la técnica del Lugar de Raíces : para

ello, lo primero de todo, sería dibujar un diagrama de bloques de un motor CC y adaptarlo a los valores del motor estudiado. El diagrama de bloques representado en la figura 3.20 sería un ejemplo :

Figura 3.20 : Diagrama de bloques de un motor CC.

Este diagrama corresponde a un motor de corriente continua controlado por inducido, al que se le ha conectado un sistema reductor, con el fin de adecuar el movimiento del motor al proceso de trabajo para el que se diseñó el sistema. El rozamiento y el momento de inercia se consideran despreciables en dicho sistema. Se tratará entonces de obtener un regulador de tipo P, comprobándose que resulta insuficiente. Con ello se pone de manifiesto la imposibilidad de usar este tipo de controlador de manera aislada, puesto que termina por llevar al motor a la inestabilidad. Es necesario entonces complementar este regulador P con otro de los ya vistos, que estabilice el sistema. Lo siguiente, pues, sería calcular un regulador de tipo PD, para introducir un cero en la función de transferencia. Esto implicaría un desplazamiento de las ramas del lugar de raíces más hacia la izquierda, por efecto del nuevo cero introducido. Se pasaría de un Lugar de las Raíces para el regulador P como el mostrado en la figura 3.21, a un nuevo LDR como el que se puede ver en la siguiente (Figura 3.22) :



Figura 3.21 : Lugar de Raíces del regulador P.

Figura 3.22 : Lugar de Raíces de un regulador PD.

Pudiera ser que la inclusión del regulador D fuese suficiente para que el nuevo PD cumpliese con las condiciones iniciales. Pero en caso de no ser así, sería necesario recurrir al uso de una Acción Integral, que daría como resultado un nuevo regulador de tipo PID, con un efecto en la señal como el mostrado en la figura 3.23 :

Figura 3.23 : Efecto del regulador PID.

2) Discretización del regulador continuo : una vez hallado el regulador continuo, es

necesario realizar la transformación pertinente del plano s al plano z, mediante un cambio de variable :



Tzs

11 −−=

Con este cambio, podemos hacer una transformación del tipo : Usk Uek

R(z) Us(s)

R(s) Ue(s) En el caso del LM629, a una frecuencia de 2000 Hz, el periodo sería :

segf

T 3105,02000

11 −⋅===

3) Obtención de los coeficientes : por último, sólo quedaría asociar los coeficientes Kp, Ki y Kd con los resultados de R(z), para aplicarlos directamente al LM629. Tras este ajuste teórico, la regulación resultante debería hacer aproximarse los datos con los ensayos experimentales.

3.1.5.4 Método digital directo (Método de Truxal). En la discretización de reguladores continuos, la solución a la que se llega, normalmente, no es única; esto es fácilmente comprensible teniendo en cuenta que el método de obtención del equivalente discreto dará resultados diferentes, dependiendo del periodo de muestreo T o del orden del bloqueador usado. Es más conveniente, por tanto, usar métodos que conduzcan a reguladores exactos, de forma que la función de transferencia total del sistema satisfaga las condiciones de funcionamiento exigidas. Este método existe y, por su utilidad, está muy difundido en el diseño de sistemas discretos. Es el Método de Truxal. Se trata de un método de síntesis directa, que permite calcular el regulador R(z) de una forma algebraica, de forma que el sistema total tiene una función de transferencia M(z) concreta y fijada previamente, que se denomina modelo. En síntesis, el sistema consiste en igualar la expresión de la función de transferencia total del sistema con la del modelo, para así despejar la función de transferencia correspondiente al regulador. Para desarrollar este sistema se usa un bucle de realimentación simple, como se puede ver en la figura 3.24 :

Figura 3.24 : Diagrama de bloques para el Método de Truxal.



De este modo la transferencia salida-entrada viene dada por la expresión :

)()()·(·)·(1

)(·)·()()( zM

zHzGBzRzGBzR

zXzY

=+

=

Siendo M(z) un modelo considerado como de referencia y cuyo comportamiento es fijo y conocido. De esta expresión, se podría despejar una función de transferencia del regulador buscada, R(z) :

)()·(·)(·)()(

zMzGBzGBzMzR

−=

El principal problema de este método es la elección de la función de transferencia del modelo, M(z). Este modelo debe cumplir las especificaciones dinámicas y de régimen permanente establecidas y además, que sea posible su realización física. Esto se logra comprobando el cumplimiento de estos tres requerimientos : 1) Condición de realización física : es el principio de causalidad, por el cual, al resolver el

regulador R(z), éste debe ser realizable físicamente. Es decir, la salida en un instante ha de depender de la entrada en ese instante y en instantes anteriores y de la salida en instantes anteriores. Matemáticamente, esto se traduce en que el grado del numerador del modelo ha de ser menor o igual que el grado del denominador.

2) Condición de simplicidad : implica que el regulador que se espera obtener se debe

poder implementar en un computador con el menor tiempo de ejecución posible. 3) Condición de estabilidad : la elección del modelo ha de asegurar la estabilidad del

modelo total realimentado. Una vez discretizado el modelo del motor por las técnicas convencionales y elegido el modelo conveniente que cumpla con estos tres requerimientos, se asocian los términos de R(z) con los coeficientes Kp, Ki y Kd del regulador, que para el motor Maxon sería :

∑=

−− −++=K

ikkdkkk eeKeKieKpU

011 )(·

256·

3.1.6 El integrado 82C55A de Intel. En los Sistemas de Control usados hoy en día en los procesos industriales predominan de manera rotunda los que utilizan entradas / salidas digitales o analógicas con cableado para cada una de ellas, sin embargo en un futuro próximo es previsible que progresivamente pasen a utilizarse de forma predominante las E / S digitalizadas.



El circuito típicamente utilizado para las entradas / salidas digitales con cableado dedicado para cada una de ellas es como se indica en la figura siguiente (Figura 3.25) :

Figura 3.25 : Circuito E / S típico.

El circuito se cierra con el interruptor correspondiente en la entrada, cuyo estado se desea conocer, y con un canal de una tarjeta del sistema. Este canal ofrece una impedancia considerable al circuito, de forma que cuando el contacto exterior cierra, la intensidad suele ser de algún miliamperio. Se consume relativamente poca energía para conocer el estado de la entrada. 3.1.6.1 Introducción. El controlador utilizado en este proyecto es el chip 82C55A de Intel, el cual es capaz de gestionar puntos de entrada / salida digitales a través de la tarjeta de comunicaciones instalada en el ordenador. El Intel 82C55A es una versión industrial CHMOS de alto rendimiento (con 5200 transistores) del estándar 8255A, dispositivo programable para entradas y salidas (E / S), diseñado para ser empleado con microprocesadores Intel, aunque también soporta la mayoría de las demás plataformas. Este integrado posee un puerto de control y 24 pines o patillas en tres puertos (PA, PB y PC), configurables como entradas o salidas independientemente y programables en dos grupos (A y B) de 12 pines mediante tres modos de operación (0, 1 y 2), que a continuación se describen brevemente. Más adelante, se entrará más en profundidad en el funcionamiento del chip en Modo 0, puesto que se trata del modo usado en este proyecto. • Modo 0 : cada grupo de E / S puede ser programado en paquetes de 4 bits, que pueden

ser tanto entradas como salidas. • Modo 1: cada grupo puede programarse para tener 8 de sus líneas como entradas o

salidas y las 4 restantes se usan para intercambios del tipo handshaking así como el control de las interrupciones.

• Modo 2 : es el llamado modo en bus direccional, que usa 8 líneas como un bus y el resto

para intercambios handshaking.



3.1.6.2 Especificaciones técnicas del 82C55A. Las características más importantes de este integrado son:

- Compatibilidad con todos los productos de Intel y la mayoría de procesadores del resto de fabricantes.

- Alta velocidad, superior a los 8 MHz.

- 24 pines, programables como entradas o salidas.

- Bajo consumo, por su tecnología CHMOS.

- Compatibilidad absoluta con la familia TTL.

- Posibilidad de lectura / escritura con control de los puertos.

3.1.6.3 Funcionamiento general. Como se mencionó anteriormente, la función de este integrado es la de servir de nexo de unión entre el sistema de movimiento mediante el motor CC y el computador que lo controla, en lo que se refiere a las señales digitales. La configuración funcional del 82C55A se realiza normalmente a través de un sistema software, que manda un paquete de información al chip con el modo de funcionamiento, el bit set, el bit reset, etc., e inicializando su configuración. Como se ha mostrado, esta interfaz contiene tres puertos, llamados PA, PB y PC, todos ellos configurables de múltiples maneras, según las necesidades del sistema. Los bits de estos puertos se encuentran reunidos en dos grupos, A y B, tal y como se ve en la figura 3.26 :

Figura 3.26.

Los modos de funcionamiento para los puertos PA y PB se definen por separado, mientras que el puerto PC se divide entre los dos grupos. Todos los registros de salida, incluyendo los estados de los biestables, se inicializan cuando se cambia el modo, pudiéndose éstos combinar en la búsqueda de la solución más adecuada. El funcionamiento del integrado varía según el modo que se elija, siendo en este proyecto el Modo 0 el que se usará. A continuación, se explicará en qué consiste este modo en concreto.



3.1.6.4 Funcionamiento en Modo 0. Es el modo básico utilizado para pequeñas aplicaciones industriales. El funcionamiento en este modo emplea únicamente entradas y salidas para cada uno de los tres puertos, no requiriendo del método handshaking, pues los datos se escriben o leen directamente sobre el puerto específico. Este modo se caracteriza por : 2 puertos de 8 bit (PA y PB), y otros 2 puertos de 4 bit (PCH y PCL).

Cada puerto puede configurarse como entrada o como salida independientemente.

Las salidas son cerradas, mientras que las entradas son abiertas.

Así pues, de este modo surgen 16 posibles configuraciones, según el estado del puerto de control, como se resume en la figura 3.27 :



Figura 3.27 : Posibles configuraciones de los puertos en Modo 0.



Cuando el 82C55A es programado en modo 0 como una salida, cada puerto tiene ligeras diferencias en cuanto a su lectura. El valor leído desde el puerto PA representará físicamente el estado de esa patilla de salida. Así, si esa patilla está puesta a tierra, el valor leído será siempre 00H, sin preocuparse por el valor escrito. Sin embargo, los valores leídos de los puertos PB y PC son diferentes. Estos valores representarán el estado de la salida cerrada, no el estado físico y, si los puertos PB y PC son puestos a tierra, el último valor escrito será el valor leído, sin preocuparse del estado físico de la patilla. 3.1.6.4 Aislamiento optoelectrónico. Cuando en un sistema hay que conectar el procesador central a elementos que no están alimentados por su misma fuente de alimentación, hay que prever la existencia de diferencias de potencial importantes entre los terminales de masa respectivos. Este punto se pone de manifiesto en el controlador digital SMCC-01, que tiene la posibilidad de unir la masa del ordenador con la masa de la fuente exterior, mediante el conector JP1 (En el caso de este proyecto, dicho jumper fue finalmente cortocircuitado). Mientras las señales procedentes de los sensores suelen ser analógicas, los procesadores son digitales y la comunicación con otros sistemas se prefiere que sea también digital, entre otras razones por su mayor inmunidad ante las interferencias. Esta inmunidad se logra eligiendo convenientemente el tipo y el código de transmisión, así como reuniendo características adecuadas en el entorno. En el ámbito de la realización física, el empleo de cables apantallados y la disposición de las tomas de masa confieren una mayor inmunidad al sistema ante interferencias, aspectos no tenidos en cuenta en el proyecto debido a su carácter experimental. El aislamiento en la adquisición o distribución de señales es necesario cuando hay diferencias de potencial elevadas entre las masa de distintos elementos del sistema, cuando se transmite a larga distancia, o simplemente cuando hay subsistemas con fuentes de alimentación independientes. Este es el caso del ordenador, donde tanto la CPU, como el motor y los interruptores, tienen sus propias fuentes de alimentación en cada caso. Las señales se aíslan normalmente mediante unos dispositivos llamados optoacopladores, que consisten en un diodo emisor de infrarrojos y un fotodetector (fotodiodo o fototransistor). Todos los optoacopladores son intrínsecamente unidireccionales, y esto evita que posibles interferencias e incluso cortocircuitos en el circuito de entrada (motor) pasen a la salida (CPU). En un optoacoplador se combinan una fuente de luz, normalmente un LED infrarrojo de AsGa, y un fotodetector de Si (Ver figura 3.28), que puede ser desde un simple fotodiodo hasta una combinación de éste con un circuito integrado que incluya un regulador de tensión y un circuito elemental para el procesado de la señal (disparador Schmitt,...). Aunque también es posible formar un optoacoplador mediante componentes discretos, el diseño con elementos integrados ofrece muchas más ventajas.



Figura 3.28 : Constitución de un optoacoplador.

Los optoacopladores se clasifican según la señal de entrada que aceptan y según el tipo de salida que ofrecen, mientras que sus características básicas son las relativas a la transferencia y al tipo de aislamiento entre el emisor y el receptor. Algunos tipos de optoacopladores disponibles comercialmente son los mostrados en la Figura 3.29.

Figura 3.29 : Tipos de optoacopladores.

En este proyecto, la tarjeta de control del SMCC-01 posee a la entrada del 82C55A un conjunto de 8 integrados de 8 pines. Estos pequeños circuitos integrados, son optoacopladores QTC2531, capaces de aislar dos bit cada uno. En la figura 3.30 puede verse un pequeño esquema de las conexiones del circuito, mientras que en la figura 3.31 se puede observar una imagen de detalle de la tarjeta de control, con una vista en primer plano de los optoacopladores :



Vcc, +24V

I=10mA 47KΩ

QTC2531

Microinterruptor

Señal optoacoplada

Figura 3.30 : Esquema del optoacoplador QTC2531.

Figura 3.31 : Detalle de los optoacopladores en la tarjeta de control.

3.1.6.5 Aplicación al sistema actual. Este apartado del control de las señales digitales resulta especialmente importante en la colocación y programación de los finales de carrera del carril lineal. Estos puntos están representados por interruptores, que se encuentran en conducción o no, según la posición de la plataforma del carril. Cuando la plataforma se desplaza, en el recorrido, se encontrará con alguno de estos microinterruptores, que están conectados, de manera que transmiten 0 o 1 al controlador. El control del carril exige cuatro puntos de referencia de posiciones, ocupados por otros tantos interruptores : 1) Representa la situación de principio de carrera en condiciones normales, es decir, en

funcionamiento correcto del motor. 2) Es el opuesto del anterior y representa la posición final extrema a la que puede llegar el

carro en un funcionamiento controlado. 3) y 4) Interruptores de emergencia, encargados de cortar la alimentación del motor en

caso de pérdida del control del software, lo que evita un daño irreparable en el motor.



Por motivos de comodidad, el número 2 puede ser obviado, ya que existe la posibilidad de llevar una cuenta mediante software de la posición del motor en todo momento, por referencia, de la plataforma. Así, únicamente los tres puntos restantes son necesarios, y se distribuirían como se muestra en la figura 3.32.

Figura 3.32 : Posicionamiento de los interruptores en el carril. Plataforma

Limite inicial Principio de carreraLimite final

El conexionado del interruptor de Principio de carrera es sencillo. Está conectado, por un lado, a la fuente de tensión del sistema, en este caso a 24 V. Por otro lado, también está conectado a la toma frontal de entradas digitales de la tarjeta de potencia,. De este modo, y como se verá más adelante, la tarjeta siempre está recibiendo 0 voltios cuando la plataforma no está en la posición de inicio de carril. Cuando se alcanza esta posición, el interruptor se pulsa, cambiando de estado y se reciben 24V. La señal pasa a un optoacoplador y de ahí al 82C55A, que la interpreta como 0 o 1 antes de enviarla a la tarjeta de control en el ordenador. Las conexiones necesarias se explicarán en detalle en el apartado 3.1.7. En cuanto al circuito de interruptores de emergencia, aunque tiene una función completamente diferente, presentan una conexión parecida. Se encuentran en serie con la alimentación del motor, de modo que en estado de reposo los microinterruptores se encuentran cerrados (alimentando al motor) y al ser pulsados se abren, cortando la alimentación del motor, lo que hace que se detenga el movimiento de la plataforma. El motivo de este circuito es que cabe la posibilidad de que la señal de principio de carrera falle por diversos motivos : por el software, por perturbaciones, por rotura del interruptor, etc. Esto podría provocar graves daños en el motor si no se detiene a tiempo, pues al llegar al límite del carril, y ante la imposibilidad de seguir moviéndose, el inducido se detendría, aumentando mucho su intensidad y terminaría por quemarse, quedando inservible el motor. Al estar este circuito de seguridad, antes de que ocurra, se pulsaría el interruptor, cortando la alimentación del motor y evitando que se llegue a la situación limite. Para la programación del movimiento del carril, el fabricante del controlador SMCC-01 permite únicamente la configuración del grupo A de patillas, que engloba al puerto PA y a la parte alta del puerto C. Como hemos visto, el puerto PA es el único que muestra directamente el estado físico de la patilla que representa. En este caso, no interesa escribir nada en los puertos, sino simplemente leerlos y, en concreto, leer una señal eléctrica, es decir, un estado físico. Por este motivo se recurre a la programación del puerto A. En cuanto al modo de funcionamiento se recurre al modo 0, por ser el más común y sencillo de todos ellos. De las 16 posibles configuraciones propuestas en la figura 3.27, se podrían utilizar cualquiera de las que van de la 8 a la 15 (PA como entrada), escogiéndose de entre ellas la número 8 (Figura 3.33) :



Figura 3.33.

Para ello se escribe en el puerto de control 90H. Una vez se tiene el control configurado, es necesario poder leer el puerto PA, mediante las funciones implementadas para el controlador. Se necesita entonces conocer la dirección del puerto, a través de los datos del fabricante del dispositivo :

- Puerto A = Dirección base + 12. - Puerto B = Puerto A + 1.

- Puerto C = Puerto A + 2.

- Puerto de control = Puerto A + 3.

Pero Windows NT, que es el sistema operativo sobre el que se ejecuta la aplicación de control, ya no permite acceder a los puertos de hardware directamente, lo que imposibilita una comunicación directa con los dispositivos de entrada de datos de la aplicación. Las posibles soluciones a este problema son :

- Crear un controlador para NT : resulta complicado y tedioso. - Comprar un controlador universal : potentes, aunque muy caros.

- Usar distribuciones gratuitas : permiten operaciones básicas de entrada y salida.

Una vez se tiene abierta la posibilidad de acceder al hardware por cualquiera de estos métodos, utilizando las herramientas administrativas se puede ver la dirección base, por ejemplo 0378H. Una vez hecho esto, basta con leer directamente el dato del puerto que ya vendrá dado como 0 o 1. Durante este paso se plantea un segundo problema, como es el efecto de los rebotes en el interruptor. Ante esto se puede diseñar un supresor de rebotes por hardware, como el mostrado en la figura 3.34, o por software. En este proyecto se recurrió al segundo método, implementando un algoritmo que lee el puerto durante un cierto tiempo (100 ms) y haciendo que, si en ese intervalo el valor se mantiene constante, se valide el dato de entrada.



Figura 3.34 : Supresor de rebotes basado en un Trigger de Schmitt.

Así, en el funcionamiento normal del carril, se hacen lecturas continuamente del puerto donde se coloca el valor del estado del interruptor. Si al hacer una lectura del puerto se ve que el motor no se encuentra al principio de carrera, es posible llevarlo allí mediante un movimiento del carril, a través del programa que lo controla. En ese momento se ejecuta una función que mueve el motor hacia atrás mientras lee el puerto, hasta que se detecta un 1 en el interruptor de principio de carrera, instante en el que realiza una parada suave del motor, según el perfil trapezoidal que se mostró anteriormente. Con este sistema, se puede controlar de manera fiable el movimiento del motor del carril, con lo que sólo queda la implementación física del dispositivo. 3.1.7 Implementación del carril lineal. Como se vio en los apartados anteriores, el sistema implementado constará de diversos módulos, conectados mediante circuitos eléctricos o cables de comunicación de datos, que se detallarán en los siguientes apartados del informe. Aunque se explicará la conexión y la función de cada una de estas partes, no se incluirá en este informe el proceso de diseño y construcción de cada uno de los dispositivos, puesto que para conocer el resultado general, dichos conocimientos tampoco son determinantes. 3.1.7.1 Vista general del sistema. El sistema se compone de un ordenador personal, llamado Heissenberg (El nombre no es una mera frivolidad, sino que viene de la necesidad de identificar los distintos ordenadores que componen el dominio GVA-ELAI), una fuente de alimentación de corriente continua estándar, un controlador digital SMCC-01, con los componentes de control y potencia ya vistos y, finalmente, el carril de desplazamiento. En el esquema (Figura 3.35), se pueden ver líneas de colores que representarán los distintos circuitos eléctricos y de datos que comunican el sistema, y que se detallarán a continuación :



Carril

Tarjeta de potencia

Fuente de alimentaciónPC

Figura 3.35 : Esquema de conexiones del carril. 3.1.7.2 Circuitos eléctricos y de datos. Como se puede apreciar en el esquema, el sistema incluye cinco circuitos eléctricos, que se detallan a continuación. para mayor facilidad en la comprensión de las conexiones, se muestran en diferentes colores. Los circuitos eléctricos usados son los siguientes : • Alimentación para la tarjeta de amplificación : es imprescindible que la corriente que

alimenta el motor pase primero por la tarjeta de amplificación, que estabiliza la alimentación y protege el sistema de picos de tensión o corriente. Este circuito se realiza con cable flexible de cobre de 1 mm2 de sección

• Alimentación del motor de corriente continua del carril : la tarjeta de potencia está diseñada para controlar hasta cuatro motores, desde estos interruptores y en este caso, se colocó el motor en la posición 2. El montaje implementado es a la vez un sistema de seguridad para evitar que el motor se pueda dañar. También en este caso, se usó cable flexible de cobre de 1 mm2 de sección

• Control del motor del carril, desde la tarjeta de potencia : a través de la tarjeta de amplificación, también se controla la posición del motor, así como los movimientos que desarrolla. para esta conexión se necesita cable paralelo de 10 hilos, de los cuales sólo se conectan los números 1, 6, 8, 9, y 10. El resto de los hilos se deben dejar sin conectar.



• Alimentación y control del microinterruptor de control de posición inicial : este circuito es el encargado de controlar las funciones de dicho microinterruptor, que se usa para inicializar los movimientos del carril. En este caso se hacen dos conexiones. Por un lado, se conecta a la fuente de alimentación mediante cable flexible de cobre de 1 mm2 de sección. Por otro lado, se conecta a la tarjeta de amplificación mediante un cable plano de 16 hilos, de los cuales sólo se usarán los números 1, 12 y 16, conectándolos como se verá más adelante.

• Conexión entre el PC y la tarjeta de potencia, a través de la tarjeta de control : es el encargado de que el control del motor se pueda hacer cómodamente desde el PC. Se deberá usar un cable plano de 37 hilos.

3.1.7.3 Componentes del carril. - La fuente de alimentación de corriente continua : debe poder regularse en tensión e

intensidad y, al menos, debe ser capaz de suministrar 24 voltios en continua y hasta 2 amperios de intensidad. En este caso, se usó una fuente que podía suministrar hasta 70 voltios y 2 amperios. Puesto que la tensión nominal de trabajo del motor es de 24 voltios, ésta debe ser la tensión que se le debe poner a la fuente. Pese a la fiabilidad que pueda tener la fuente, es muy importante medir con un polímetro la tensión que se tiene en la acometida de los cables antes de conectar el motor; si no, se puede poner en peligro la integridad del motor.

- El controlador SMCC-01(Componente de potencia) : ya se explicaron anteriormente las

características técnicas de esta tarjeta. Esta tarjeta dispone de una sola entrada de alimentación, aunque tiene tres salidas de alimentación diferenciadas, una para cada motor a controlar. Asimismo, dispone de una salida de control para cada uno de los posibles motores conectados, de una salida común para la conexión con el PC y de una entrada digital de datos para comunicarse con el exterior. En este proyecto, dicha entrada es la que se conecta al microinterruptor de posición inicial. La implementación de la conexión se explica en detalle en el apartado dedicado a los microinterruptores.

- Componente de control : aunque pertenece también al controlador SMCC-01, está

separado de él. Este dispositivo es el que procesa todo el movimiento de control del sistema y está conectado a una ranura ISA del ordenador sobre el que corre la aplicación de control. Es, por tanto, la encargada de comunicar la tarjeta de potencia con el ordenador, a través de un conector de bus paralelo, de 37 cables.

- El carril lineal : es un soporte de metal, al cual se le ha acoplado el motor de corriente

continua Maxon-968. Lleva acoplado un sistema reductor, que permite acoplar el giro del motor a las velocidades necesarias para que las aplicaciones puedan trabajar. Al carril se le han acoplado tres microinterruptores digitales, uno para el control de la posición inicial de la plataforma móvil del carril, mediante la entrada digital de datos; y otros dos para implementar un circuito de seguridad para el motor, conectándolos en serie con la alimentación del mismo. El tercer microinterruptor del carril está situado en una posición lo más a la derecha posible, para permitir un rango de movimientos lo más amplio posible, pero siempre dejando un margen de actuación para el circuito de



seguridad. Lleva acoplado el motor, encargado de producir el movimiento, y el encoder digital para controlar el giro.

- Los microinterruptores : como ya se ha mencionado, son casi la parte más importante del

sistema, por cuanto garantizan que no haya accidentes que malogren el motor. Su aspecto, esquemáticamente, y sus conexiones internas, son las que se pueden ver a continuación en la figura 3.36 :

COM NO NC COM NO NC

Figura 3.36 : Esquema y conexiones del microinterruptor.

Se puede observar que las patillas COM y NO están siempre conectadas, haciendo un cortocircuito, por el que puede pasar la corriente. Al activarse la palanca del microinterruptor, el cortocircuito conmuta a estar entre COM y NO, quedando cortado el anterior flujo de corriente y estableciéndose uno nuevo. En el sistema implementado, los microinterruptores extremos de emergencia se conectaron como se puede ver en el esquema (Figura 3.37), de forma que al dejar la patilla de NO sin conexión, la corriente en el motor se interrumpirá al activar la palanca.

Figura 3.37 : Conexión de los microinterruptores en el carril. Al (+) del motor

Límite derecho

Al (–) de la salida de la tarjeta de potencia

Límite izquierdo

El tercer microinterruptor se conecta a la entrada de datos de la tarjeta de potencia, así como a la fuente de alimentación, tal y como se indica a continuación : • La patilla COM : se conecta al cable número 12 del bus de entrada digital de datos de

la tarjeta de potencia. • La patilla NO : se conectará a la salida positiva de la fuente de tensión, así como al

cable 16 del bus de entrada digital de datos de la tarjeta de potencia.

• La patilla NC : Se conectará a la salida negativa de la fuente de alimentación y al cable 1 del bus de entrada digital de datos de la tarjeta de potencia.



Con esta situación el microinterruptor envía a la tarjeta de potencia un 0 en la posición normal, cuando la plataforma no está en la posición de inicio de carril. Cuando llega a dicha posición acciona el microinterruptor y se conmuta su estado, pasando a indicar un 1 lógico, que es interpretado por la tarjeta como que la plataforma está en la posición inicial, deteniendo el motor con una desaceleración controlada. En la figura 3.38 puede verse un detalle de la situación de los microinterruptores de limite derecho (3.38.a), y de inicio de carril (3.38.b) en el sistema:

Figura 3.38: Detalle de los micronterruptores.

B A

3.1.7.4 Puesta en marcha del sistema. Después de conectados todos los componentes, llega la hora de poner en marcha el sistema. El sistema que se va a montar debe trabajar con un ordenador en entorno grafico Windows NT (Aunque también se tiene intención de que se pueda hacer correr la aplicación tanto en Windows 2000 como más adelante, en Linux) La gran desventaja que presenta este sistema operativo respecto a otros de la familia Windowsmás antiguos es la imposibilidad que existe de acceder a los puertos del ordenador directamente. Quizás sea una ventaja en cuanto a la fiabilidad y la seguridad del sistema, pero en este proyecto, se ha convertido indudablemente en una gran desventaja. En cualquier caso, para solucionar esto, se deberá recurrir a alguna ayuda que permita solventar este inconveniente. En el caso que nos ocupa, se recurrió a la instalación de una aplicación shareware, llamada Tinyport, que básicamente es un controlador que permite a las aplicaciones leer y escribir directamente en los puertos. La instalación y configuración de este programa no presenta mayor dificultad que cualquier otro programa de Windows, y cualquier usuario con conocimientos medios podría poner en marcha el sistema, basta con seguir las instrucciones que se incluyen en el archivo .zip donde viene el archivo ejecutable. Se explicarán los pasos a seguir en la instalación y configuración en un capitulo especifico. Terminada esta instalación, el sistema está preparado para empezar a trabajar, utilizando cualquiera de las aplicaciones de control del carril ya existentes. Tras probar los programas, se puede ver que efectivamente, el carril se mueve y la plataforma se desplaza hasta los puntos extremos de seguridad con total normalidad y que los desplazamientos se hacen con aceleraciones y deceleraciones controladas, según los perfiles trapezoidales deseados.



3.1.7.5 Problemas surgidos. Durante el proceso de implementación del carril fueron surgiendo ciertos problemas de diversa índole, que fueron solucionándose de una u otra manera. Sin embargo es indudable que es importante reseñarlos, puesto que en caso de que se implementase un nuevo carril a partir de este, o simplemente, se cambiase su ubicación dentro del laboratorio se volvería a perder tiempo en resolver fallos que ya están catalogados. - Fallos en la alimentación : como ya se menciono, el motor tiene una tensión nominal con

la que debe trabajar para alcanzar su mejor rendimiento. Por debajo de esta tensión, el motor puede verse obligado a consumir más intensidad de la que está preparado para soportar, quemándose de manera irreversible. Cuando el motor trabaja con una tensión menor de la nominal, no se alcanzan las velocidades deseadas y los perfiles de trayectoria no son trapezoidales, sino que se vuelven irregulares. para remediar este fallo, simplemente es necesario acostumbrarse a medir la tensión suministrada al motor, antes de conectarla, con un polímetro, cerciorándose con ello de que es la deseada.

- El componente de control del controlador SMCC-01 : en el esquema de la tarjeta,

mostrado en la figura 3.30, se puede observar que el circuito eléctrico del optoacoplador, que binariza la señal emitida por el microinterruptor, lleva una resistencia de 4,7KΩ. En origen, dichas resistencias, una para cada optoacoplador de la tarjeta, no están incluidas en la circuitería. Sin ellas, la señal que le llega al optoacoplador no es clara y el sistema no puede pasar los datos del estado del microinterruptor de inicio de carril al ordenador, con lo que el control de esta función resulta imposible. En caso de no estar, la plataforma se movería con normalidad las distancias consignadas, pero al recibir una orden de ir al inicio de carril, se movería sin control hasta el microinterruptor de emergencia. Por lo tanto, es necesario soldar estas resistencias a la tarjeta antes de instalarla en el sistema.

- Alimentación del SMCC-01 : como se ha visto en los esquemas del dispositivo, la tarjeta

de potencia del controlador, lleva una entrada para la alimentación del dispositivo. Esa entrada de alimentación luego distribuye corriente a los motores conectados, en el caso de este proyecto, al motor 2, que es el que se conectará por defecto. El problema surgió cuando el sistema echó a andar, ya que no se movía correctamente, y lo hacía al revés. Comprobando con el modelo que se había tomado como referencia, se veía que las conexiones eran exactamente iguales. Así que se tomó otro sistema como referencia, que estaba en uno de los laboratorios del Departamento, destinado a otra aplicación (Era un sistema para el control de motores en una de las prácticas de la asignatura de Servosistemas). En dicho sistema, que funcionaba correctamente, se pudo observar que la polaridad de la alimentación al motor desde el controlador estaba colocada al revés, es decir, la salida positiva iba conectada al negativo del motor, y la salida negativa al positivo. De ello se dedujo que la serigrafía en el controlador que indicaba la polaridad de la salida de tensión, estaba equivocada, y era al contrario de como estaba puesto. Se probó, por tanto, a conectar los cables de alimentación al revés de como se indica en el controlador, con lo que el sistema ya funcionó con normalidad.

- Entrada de datos digitales del SMCC-01 : a la hora de conectar el microinterruptor de

posición inicial al controlador, se sabe que los pines que deben conectarse son los



números 1, 12 y 16. En el caso de los pines 1 y 16, la referencia por donde empezar la cuenta de pines no es determinante, puesto que se encuentran en los extremos del conector y los dos pines de cada extremo están cortocircuitados internamente con el otro pin de ese extremo. Por lo tanto, a efectos de conexión, da lo mismo usar el pin 1 o el 2, así como da igual usar el 15 o el 16. Pero no ocurre lo mismo con el pin número 11. En este caso, la función que transmite, varía mucho de la del pin 12, con lo cual hay que tomar el punto de referencia de la cuenta muy cuidadosamente. El fabricante usa como referencia de la cuenta el primer pin a la derecha de la muesca, cuando se ve el conector desde el exterior del SMCC-01. Con esto, la conexión del cable de 16 hilos, debe ser como la que se muestra en la figura 3.39 :

o La patilla COM del microinterruptor al cable número 12. o La patilla NO ira tanto al cable 16 (o al 15, puesto que están en corto).

o La patilla NC ira al cable 1 (o al 2). En caso de usarse el pin 11 en lugar del 12, el sistema no detectaría la señal enviada por el microinterruptor, con lo que la plataforma llegaría al limite de seguridad y se cortaría bruscamente el circuito.

16 14 12 10 8 6 4 2

15 13 11 9 7 5 3 1

Figura 3.39 : Pineado del conector de E / S digitales del SMCC-01 3.1.8 Instalación de Tinyport. Como se mencionó anteriormente, el ordenador que controla todo el sistema, Heissenberg, estaba integrado en un dominio de trabajo, GVA-ELAI, basado en el sistema operativo Windows NT, en concreto en la versión 4.0. Dicho sistema operativo, dentro de la seguridad que ofrece a nivel de gestión de usuarios y de accesos desde ordenadores externos al dominio, tiene propiedades que lo hacen poco recomendable al trabajo con dispositivos externos. Una de esas desventajas, es la gestión de los puertos hardware del equipo. El sistema operativo, para controlar los accesos de las aplicaciones a los puertos y así asegurar que no se convierten en una puerta abierta para los usuarios no autorizados, bloquea dichos puertos. De este modo, sólo los programas que tienen un controlador adecuado para el acceso a un determinado puerto pueden acceder al mismo, para leer o escribir. En este proyecto, el posicionamiento del carril en el punto de inicio depende de las señales digitales que manda un microinterruptor a uno de los puertos ISA del equipo, y resulta un proceso critico, ya que el sistema depende de esa inicialización. Por ello, para permitir una gestión directa de los datos en el microinterruptor por parte del usuario, es necesario instalar en el sistema operativo un controlador. Con dicho programa se “engaña” al



sistema operativo, haciéndole creer que el acceso está autorizado y así se pueden manipular los datos que llegan al puerto consignado por el controlador. Ya se vio que existen varias posibilidades, pero en este proyecto, se opto por el uso de una aplicación de distribución limitada, que permite la gestión de los puertos de NT. El programa en cuestión se llama Tinyport, y consiste en un archivo .zip, que puede ser descargado gratuitamente de Internet. El programa requiere de la instalación de un controlador (Tinyport.sys) en la carpeta de drivers de Windows NT (Unidad:\Windows\System32\Drivers), y de una librería, (Tinypio.dll)en la carpeta System32 (Unidad:\Windows\System32). Una vez hecho esto, sólo queda lanzar la utilidad que permite configurar el puerto que se quiere hacer accesible en el ordenador. Para ello, basta con abrir una ventana de consola de MS-DOS e ir hasta el directorio donde se tiene el programa Tinyport. En el directorio se teclea : Tpconfig A B C D E F Donde : A = Tipo de bus : aquí se debe codificar el tipo de bus que se quiere hacer accesible, en este caso, el bus ISA. B = Número de bus : la bahía ISA que debe manipularse, ya que puede haber más de una. C = Dirección de memoria de inicio : la primera dirección de memoria que se va a dejar accesible en este dispositivo para lectura /escritura de datos. D = Direcciones de memoria a reservar : número de direcciones de memoria consecutivas a desproteger, a contar a partir de la anterior. E = Nombre del registro del programa : recuérdese que no es gratuito, sino shareware. F = Número de registro del programa : se suministra al registrarse. En concreto en este proyecto, la tarjeta de control se encuentra instalada en la bahía ISA0, y como dirección de memoria se colocará en la 0300h, que se ha comprobado que no genera conflictos con otros dispositivos del sistema. Por lo tanto, la orden que habría que teclear sería : Tpconfig ISA 0 300 4 Nombre NºRegistro Estos sencillos pasos instalarían el controlador en el sistema. Sólo quedaría, para mayor comodidad, automatizar el inicio del sistema, para que se lanzase el controlador cada vez que se arrancase el sistema. para ello, habría que ir al panel de control del sistema y abrir el administrador de servicios. En el servicio Tinyport, cambiar el modo de inicio de Manual a Automático. Con esto, el controlador se arrancaría cada vez que se entrase en Windows, con lo que únicamente se necesitaría arrancar la aplicación de control para poder manejar el carril.



3.2 Descripción del sistema de visión. El sistema de visión es el encargado de la parte de recepción y tratamiento de las imágenes del sistema. Dichas imágenes servirán para luego realizar los distintos seguimiento de objetos que se pueden hacer. En el presente capítulo, se intentará mostrar de manera concisa los dispositivos que forman esta parte del sistema de percepción artificial. Se mostrarán las características técnicas más importantes de cada elemento, así como las conexiones necesarias entre ellos y el ordenador Heissenberg y también se tratarán los programas necesarios para hacer que el sistema funcione. 3.2.1 Introducción al sistema. El sistema de Percepción Artificial, implementado por Alamo, fue mejorado posteriormente por Yubero, que añadió algunas funciones más, y amplió el campo de uso del sistema al sistema operativo Linux. Con ello, el sistema de visión era autónomo y permitía ya hacer un seguimiento de objetos al uso, pero no estaba completo. Quedaba pendiente su integración con el sistema de movimiento del carril para permitir hacer una autocalibración completa y eficiente. Esta parte de integración implicaba el desarrollar un nuevo programa que permitiese controlar el carril y la cámara en una nueva aplicación, lo que suponía llevar parte de las funcionalidades de la cámara a la nueva aplicación. El sistema de visión de este proyecto está formado por dos elementos principales. Por un lado, está una cámara de video, de tipo Pan-Tilt, que es la encargada de la recepción de imágenes del escenario. La otra parte, es una tarjeta Matrox Meteor, que está instalada en Heissenberg. Esta tarjeta es la encargada de recibir las señales de salida de la cámara y es capaz de realizar algunas labores de procesamiento de la imagen, con los programas que la acompañan. Pero no obstante, los procesos que realiza son bastante simples y genéricos y no cumplen en absoluto con las finalidades que se persiguen en este proyecto. Así pues, es necesario el uso de un sistema que permita desarrollar las capacidades necesarias de este proyecto. para ello, se recurrió a la instalación de unas librerías de tratamiento de imágenes, también de Matrox, las MIL (Matrox Imaging Library). Con este programa, sí es posible acometer el proceso del tratamiento de imágenes para el seguimiento de objetos. También hay que mencionar que el ordenador donde se ha instalado todo el sistema de visión, no sirve únicamente para el procesamiento de imágenes, sino que también es el encargado de mover la cámara. Recordemos que en este proyecto se está tratando de desarrollar un sistema de Percepción Artificial completamente autónomo. para ello, el sistema debe ser capaz de controlar sus movimientos de manera autónoma, lo que significa que alguno de ellos debe ser capaz de cumplir esta tarea. Puesto que la cámara no posee las capacidades de procesamiento que requiere la tarea, parece claro que elemento encargado de acometerlas no puede ser otro que el ordenador sobre el que corre la aplicación de seguimiento. Así pues, debe haber una posibilidad de comunicación entre el equipo y la cámara, que garantice un flujo de órdenes rápido y entendible por ambos sistemas. Este protocolo viene ya implementado, y se trata del protocolo VISCA. Con él, el sistema es capaz de enviar a la cámara órdenes en un formato que es plenamente inteligible por ella. También se comentarán algunos aspectos de este protocolo en los siguientes apartados.



3.2.2 La cámara Pan-Tilt. Lo primero que se debería aclarar en este apartado es : ¿Qué es una cámara Pan-Tilt? La respuesta es bastante sencilla : es un modelo de cámara, equipado con un sistema de movimiento que le permite el desplazamiento tanto con giro alrededor de un eje horizontal (TILT) como giro alrededor de un eje vertical (PAN) (Figura 3.40). Con ella se pueden capturar imágenes digitales, que pueden ser posteriormente tratadas en un ordenador, como se hace en este caso para el seguimiento de objetos.

Figura 3.40 : La cámara Pan-Tilt Sony Evi-D31.

Existen en el mercado varios modelos de cámaras de este tipo, de distintas marcas y con distintas capacidades añadidas. La elección de este modelo en concreto, se hizo teniendo en cuenta puntos distintos. Uno de los primeros y tal vez el fundamental, fue la función que iba a tener la cámara. Su uso iba a ser fundamentalmente para seguimiento de objetos, no descartándose otras posibilidades, por lo que era imprescindible que la cámara fuera equipada con un sistema motriz de buenas prestaciones. La elección de éste es importante, ya que condicionará las futuras aplicaciones de la cámara. Se deben tener en cuenta dos datos, principalmente : 1) Capacidad de giro dentro de cada grado de libertad : es decir, no sólo importa hacia

donde gira, sino también cuanto puede girar en cada eje. 2) Velocidad de giro : este punto se puede considerar superfluo si el uso que la cámara

vaya a tener no condiciona la velocidad. En el caso que aquí ocupa, se precisan respuestas rápidas ante imprevistos, por lo que la velocidad es un valor a tener en cuenta.

Además del movimiento, existe otra serie de cuestiones a tener en cuenta en la elección de una cámara. Es decir, nótese que no sólo se trata de capturar una imagen, sino que esta imagen puede estar sometida a distintos grados de luminosidad, que ésta puede ser variable e incluso que queremos poder controlar características tales como la distancia focal o la apertura del iris. También se tuvieron en cuenta a la hora de la elección de la cámara las características añadidas que presentan los distintos fabricantes. En el caso de la Evi-D31, la colección de



funciones añadidas, así como una mejor relación calidad / precio, decantaron la elección hacia este modelo. A continuación, se verán las principales características de la cámara. 3.2.2.1 Especificaciones técnicas. La cámara tiene unas características bastante buenas, entre las que cabe resaltar el rápido sistema de movimiento en los dos ejes, zoom de hasta 12 aumentos con enfoque automático de alta velocidad, 6 posiciones de memoria, sistemas de detección de movimiento y seguimiento de objetos ya implementados, control a través del puerto serie (Bajo el protocolo serie RS-232) de un ordenador o la posibilidad de manejarla a través de control remoto. A continuación, se enumerarán las características técnicas de la cámara : • Señal de video : PAL. • Sensor de imagen : CCD color de 1/3 “. • Pixels de resolución : 752 (Alto) x 585 (Ancho). • Resolución horizontal : 450 líneas de televisión. • Resolución vertical : 400 líneas de televisión. • Zoom : hasta x12. • Distancia focal : 5.4 – 64.8 mm. • Distancia mínima al objeto : 10 mm (Zoom abierto), 800 mm (Zoom cerrado). • Rango de iluminación : 7 – 100.000 lux. • Autoexposición : Auto Iris, AGC. • Velocidad de obturación : 1/50 – 1/10.000 (Controlado por VISCA). • Ganancia : Manual / Automática (Controlado por VISCA). • Movimientos : horizontal (Pan) ±100º (Velocidad máxima 80º/s), Vertical (Tilt) ±25º

Velocidad máxima 50º/s) (Figura 3.41).



Figura 3.41.

• Salida de video : Jack RCA con 1Vp-p, Super Video, miniDIN de 4 pines. • Salida de audio : Jack RCA (Mono), con salida de 327 mV, impedancia de salida de

menos de 2,2 KΩ. • Terminal de control : RS-232C por puerto serie, mini DIN de 8 pin, 9600 baudios,

palabra de 8 bits, 1 bits de paro. • Terminal de entrada de micrófono : Mini Jack (Mono), rango de entrada de 0,775 mV, 3

V de CC para micrófonos de baja impedancia. Impedancia de entrada de más de 10 KΩ. • Terminal de tensión : 13,5 V de CC (EIAJ). • Entrada de tensión : 12 a 14 V en corriente continua. • Potencia : 10,5 W. • Temperatura de funcionamiento : 0 a 40º C. • Temperatura de almacenaje : -20 a 60º C. • Dimensiones (A x L x F) : 142 x 109 x 164 mm (Figura 3.42). • Peso : 1200 g.

Figura 3.42.



3.2.2.2 Funciones añadidas. La cámara Evi-D31 viene equipada con una serie de funcionalidades, tanto para el seguimiento de objetos (a nivel muy básico), como de detección de movimiento, así como otras opciones. Hay que resaltar que todas estas funciones no requieren programación alguna, sino que están disponibles en la cámara, a través de las opciones disponibles en el mando a distancia que la acompaña a) Localización y seguimiento de objetos - AT (Auto Tracking) : con esta función, se

localiza continuamente un objeto definido por el usuario. La cámara recoge y almacena pixels de similares características de color y brillo, alrededor del objeto definido. La cámara, entonces, realiza un seguimiento mediante un modelo basado en la refracción de luz y el procesamiento no lineal. Con ello se consigue un seguimiento real del objeto, con el inconveniente de que hay que definirlo previamente, con lo que la cámara requiere de una pequeña programación por parte del usuario antes de realizar el trabajo de seguimiento.

Se comienza iniciando el modo de reconocimiento con la tecla AT-ON/OFF del mando a distancia. En este momento aparece un marco en la imagen que muestra la cámara. Se debe mover la cámara de tal forma que dicho marco encuadre justamente lo que se quiere localizar (Figura 3.43).

Figura 3.43 : Seguimiento automático de objetos.

La cámara entonces se guiará por las características de brillo y color del objeto, así que cuanto más definidas sean estas características, mejor hará el seguimiento. Una vez seleccionado el objeto se pulsará START/STOP en el mando a distancia. Hay que resaltar que cuanto más alto sea el valor que se indica en P-T DRIVE ENTRY, más probabilidad existirá de que la localización del objeto funcione correctamente. Funciona bien únicamente cuando hay una gran diferencia entre colores, como por ejemplo, marcando un objeto azul sobre un fondo blanco. Hay tres modos de funcionamiento para esta función : a.1) Chase 1 : la cámara no se mueve, sólo se mueve la ventana, buscando el objeto

por la imagen recibida a.2) Chase 2 : La cámara intenta todos los ajustes posibles para buscar el objeto en la

pantalla. Una vez que lo ha localizado se mueve para centrarlo.



a.3) Chase 3 : se mueven a la vez la cámara y el cuadro. Puesto que los tres modos están basados en el seguimiento del objeto por colores y reconocimiento de formas, cuando se cruza otro objeto por la imagen con características aproximadamente iguales al objetivo, la cámara puede perder el objeto original, deteniéndose el seguimiento. Con las teclas del mando AE (Autoexposición y Backlight, permiten que el brillo del escenario permanezca constante en entornos con grandes diferencias de contraste) y AUTO ZOOM (control del zoom para permitir que el tamaño del objeto permanezca constante) se puede mantener el brillo y el tamaño del objeto tal y como está en ese momento. El marco normalmente aparece en el medio de la pantalla. Si se quiere que aparezca en algún otro lugar, sólo se debe pulsar OFFSET y con las flechas desplazar el marco al lugar elegido. Cuando esto haya sido hecho, se pulsará de nuevo OFFSET. Pulsando el botón ENTRY, se tienen distintas modalidades de localización :

1 Es la usada hasta ahora. 2 Cuando el objeto no se reconoce porque es muy claro o se confunde con

otro.

3 Si el error viene cuando el objeto se desplaza.

4 Si la cámara sólo reconoce el techo o la pared. Para desactivar el modo de localización se pulsa de nuevo AT ON/OFF.

b) Detección de movimiento – MD (Motion Detector) : básicamente, esta función permite

detectar la diferencia entre una imagen captada y la siguiente. La técnica usada convencionalmente en este tipo de seguimientos únicamente usaba el procesamiento del brillo de la imagen de video detectada. La Evi-D31, por otro lado, además del brillo, emplea el procesamiento del color, con lo que se logra que incluso aquellos objetos que tienen un brillo similar al del fondo de la imagen puedan ser detectados y seguidos con fiabilidad. Los cambios de luz en este modo se controlan constantemente y los datos de la imagen de referencia se ajustan automáticamente. El usuario puede definir dos áreas de detección rectangulares, de cualquier tamaño y en cualquier posición que desee. Una vez que se detecta el movimiento en las ventanas definidas, se enciende una luz roja y se manda una señal para que se transmita con el protocolo VISCA (si está activado) para avisar del suceso. Con esta señal se puede, por ejemplo, activar un sistema de grabación de video. Este modo de funcionamiento es muy versátil, puesto que permite ajustar el brillo, el color y el área de búsqueda de la imagen, y pueden activarse tanto mediante el mando a distancia de la cámara como a través de un ordenador, mediante el protocolo VISCA. Para activar este modo de funcionamiento, se comienza pulsando la tecla MD ON/OFF del mando a distancia para entrar en la aplicación. A continuación, se pulsa el botón FRAME, para indicar el marco que situará la zona de detección y con las flechas se



sitúa el marco. Se pulsa FRAME y se indica ahora su superficie, pulsándose de nuevo FRAME para finalizar. Si se desea, se puede ubicar un segundo cuadro de detección pulsando de nuevo FRAME y operando de la misma forma. Con DETECT se selecciona el cuadro de detección que se va a usar, pudiendo ser el 1, el 2 o ambos. Para comenzar el seguimiento, se pulsa la tecla START/STOP, y para finalizarlo se pulsa START/STOP seguido de MD ON/OFF. En esta aplicación surgen una serie de posibilidades en la detección de objetos : 1 El dibujo de referencia se refresca cada 0.1 s con la imagen de la cámara. 2 La imagen de referencia sólo se refresca si no se produce un cambio súbito. Si

éste se produjese, la imagen no se refrescaría. 3 La imagen de referencia es siempre la misma. Para seleccionar estas opciones, tras pulsar MD ON/OFF y START/STOP y comenzar el seguimiento de objetos, se deberá pulsar el botón MENU para entrar en el menú MD. En este menú se pueden ajustar las preferencias con las flechas y, cuando se finalizan los ajustes, se pulsa de nuevo MENU.

3.2.2.3 Conexión al equipo. En la parte trasera de la cámara, se pueden encontrar diversos conectores, que demuestran una vez más la versatilidad que caracteriza a este modelo. Las imágenes captadas pueden ser enviadas a un sistema de televisión, video, o a un ordenador, si posee la entrada adecuada. Todas estas salidas son señales compatibles, que no requieren de ningún equipo extra para la conexión. La única excepción son los ordenadores, puesto que no todos disponen de una entrada de SVideo. Esta conexión se ha ido popularizando en los últimos años, convirtiéndose en la conexión más habitual en las tarjetas graficas de hoy en día. Pero en ordenadores que dispongan de una tarjeta de video un poco más antigua, como es el caso de Heissenberg, esta conexión, no está disponible, con lo que se hace necesaria la instalación en el equipo de un equipo de captura de video (como es el caso) o de una nueva tarjeta de video, que disponga de la conexión SVideo. La segunda opción puede resultar más llamativa a primera vista, puesto que el rendimiento del ordenador se vería incrementado al sustituir un componente por otro de última generación. No obstante, en el momento en que esta decisión hubo de tomarse las pocas tarjetas que incorporaban la entrada de SVideo, tenían unos precios fuera de lo recomendable. La cámara incorpora también un conector para el control de la misma a través del protocolo VISCA y otro conector para un micrófono (puesto que también existe la opción de captar sonidos con la cámara), como se puede observar en la figura 3.44. También cabe la posibilidad de conectar hasta siete cámaras iguales y controlarlas mediante Daisy chain.



Figura 3.44 : Conexiones posteriores del a Evi-D31.

En la figura se pueden ver las conexiones posibles : - Salidas de audio y vídeo : correspondientes a los dos primeros terminales (negro y

blanco). Se conectan mediante un cable, suministrado con la cámara, a las entradas del ordenador, vídeo o televisión que correspondan.

- Salida SVideo : Este cable no es distribuido por el fabricante. - Entrada de micrófono : para incorporar sonido a las grabaciones mediante el micrófono

que se conecte al terminal. - Terminales VISCA : el primero de ellos servirá para la conexión de la cámara a un

ordenador mediante el protocolo VISCA. En el otro extremo se conectará a un puerto serie configurado en el protocolo de transmisión RS-232C. Este cable tampoco lo suministrada el fabricante, por lo que deberá hacerse. El otro terminal es para la conexión en cadena de varias cámaras e irá al terminal de transmisión con el ordenador.

- Terminal de alimentación : se conectará la clavija de la fuente de alimentación. 3.2.3 La tarjeta Matrox Meteor. Como se mencionó en el capítulo anterior, la cámara Pan-Tilt necesita de una entrada SVideo, para poder conectarse con el ordenador. Pero el ordenador que controla todo el



sistema, Heissenberg, no dispone de esta conexión, por lo que se recurrió a instalar una tarjeta controladora de video, que realizase parte del procesamiento de imágenes, al mismo tiempo que proveía al sistema de una entrada de video para conectar la cámara. En concreto, se uso una tarjeta Matrox Meteor I. Se trata de una tarjeta sencilla, de 32 bits en PCI, que permite operar tanto con imágenes en blanco y negro como en color. Con esta tarjeta se puede mostrar la imagen en tiempo real, o almacenando en memoria secuencias, en función de la velocidad del sistema en que se instala. Entre otras muchas posibilidades que ofrece la tarjeta, cabe destacar la posibilidad de mostrar en una ventana video directo de un dispositivo. Esta utilidad servirá para poder visualizar en el ordenador lo que está captando la cámara Pan-Tilt en el momento, con las ventajas de operación evidentes que ello conlleva. A la hora de capturar video, la tarjeta admite tanto RS-170/CCIR monocromo como NTSC/PAL en color y dispone de la posibilidad de conectar hasta cuatro dispositivos de captura de imágenes a la misma tarjeta al mismo tiempo. para mayor facilidad en la calibración y la configuración de la tarjeta, es posible también preprogramar el brillo, contraste y saturación de los colores de las ventanas de captura mostradas. En la figura 3.45 se puede apreciar una vista general de la tarjeta, y en la figura 3.46, un esquema del funcionamiento de la tarjeta.

Figura 3.45 : La tarjeta Matrox Meteor.

Figura 3.46: Diagrama de funci namiento de la tarjeta Meteor. o



Precisamente, en esta última imagen, puede observase la posibilidad que incorpora la

sta tarjeta soporta tasas de transferencia de video de hasta 132 Mbytes/segundo, e

.2.4 Las librerías MIL.

omo se comento anteriormente, en el mercado existen distintas opciones a la hora de

ste punto, el de los servicios adicionales que aporta cada marca fue el que determinó la

stas librerías son un paquete de procesamiento de imágenes totalmente independiente del

l programa se ha diseñado con la intención de que sea una herramienta sencilla, con un

uesto que las MIL permiten la identificación unívoca de las tarjetas instaladas en el

Meteor de hacer la adquisición de imágenes por componentes de color RGB (Del ingles Red, Green, Blue, rojo, verde y azul), que se capturan a través de distintos canales, lo que garantiza una mayor calidad en la imagen generada. Eincorpora controladores para Windows95, NT 4.0 y DOS, que se instalan en el momento de instalar las librerías de tratamiento de imágenes MIL. Por esta razón, en el apartado dedicado a la instalación de estas librerías bajo Windows 2000, se explicará como funciona la autodetección e instalación del controlador de la tarjeta. 3 Cadquirir una cámara Pan-Tilt. La decisión de comprar una u otra cámara debe hacerse teniendo en cuenta las prestaciones, el precio, las funciones para las que se va a usar, etc. Pero también es algo a atener en cuenta el soporte que cada marca ofrece para cada modelo, puesto que este punto puede ser determinante a la hora de desarrollar aplicaciones para esa cámara. Ecompra de la Meteor, por encima de otras cámaras similares. Y es que además de la cámara en sí, con la compra se incluye un CD donde, además de los controladores, se acompañan las librerías de procesamiento de imágenes MIL (Matrox Imaging Library), que, obviamente, están plenamente integradas para trabajar con la Meteor. Ehardware en el que se instalen y plenamente modular. Posee una gran cantidad de órdenes disponibles para el tratamiento de imágenes, algunas de ellas especializadas para el análisis globular, obtención patrones de medidas y OCR (Optical Carácter Recognition, reconocimiento óptico de caracteres, que permiten al ordenador “leer” un texto capturado en una imagen) y también contiene un conjunto de herramientas gráficas básico. Etiempo de aprendizaje corto, capaz de ser usado en cualquier plataforma y con procesos de gestión de imágenes completamente transparentes. Esto significa que las aplicaciones implementadas con MIL pueden correr en cualquier sistema que tenga instalada una tarjeta VGA compatible con el estándar VESA o en su defecto, que tenga una tarjeta grafica Matrox y todo ello en cualquiera de los sistemas operativos corrientes. Psistema, una misma aplicación puede ser capaz de controlar varias tarjetas al mismo tiempo. Los programas desarrollados con estas librerías, pueden interactuar con el microprocesador del sistema de manera segura y eficiente, beneficiándose el sistema de los sistemas de aceleración por hardware de las tarjetas Matrox, como es el caso de la Meteor que se usa en este sistema. Todo ello redunda en una mayor eficiencia y una menor carga



de trabajo de procesamiento para el micro, lo que permite que éste se encargue de las demás tareas, mientras la tarjeta grafica se encarga del procesamiento de imágenes. Las operaciones de procesamiento de las librerías MIL se han programado pensando en un rendimiento optimizado del sistema, a partir de las mejoras que introdujo en el procesamiento la aceleración de gráficos de Intel MMX. Como ejemplo, baste decir que en un sistema con un Pentium II con Intel MMX, las operaciones de las MIL se pueden ejecutar hasta un 400% más rápido que en un microprocesador igual sin MMX. En cualquier caso, la inclusión en este paquete de los algoritmos de convolución, usados en la aplicación de seguimiento del cable, resulta indudablemente beneficiosa para este proyecto. 3.2.5 Control del sistema. El protocolo VISCA. Las siglas VISCA vienen del acrónimo en ingles Video System Control Architecture. Como se mencionó, la cámara Evi-D31 puede controlarse desde el ordenador mediante este protocolo trasmitiendo a través del puerto serie configurado en RS-232C. VISCA es un protocolo de red, diseñado para funcionar como interfaz de distintos tipos de cámaras de video y el ordenador al que envían las imágenes. Con este protocolo se podrían conectar hasta 7 cámaras Evi-D31 a un mismo puerto serie, con parámetros para transmisión RS-232C, es decir, 9600 baudios, longitud de datos 8 bits, con un bit de parada y sin paridad. La conexión de las cámaras podría hacerse según dos estándares : • Conexión serie : también llamada en cadena, es aquella en la que una cámara está

conectada a otra, y esa otra a la siguiente, existiendo sólo una que esté conectada al ordenador. El máximo número de cámaras que se pueden conectar por éste método es de siete, asignando el ordenador la dirección a cada una. La dirección del controlador instalado en el ordenador y al cual se conecta la primera cámara, sería la 0. La de las cámaras iría de la 1 a la siete, ambos inclusive, siendo la numeración más bajo la que corresponde a la cámara más cercana al ordenador. Se muestra un esquema de conexión serie en la figura 3.47 :

Figura 3.47 : Conexión serie de varias cámaras.



• Conexión paralelo : denominamos conexión paralela aquella en la que cada cámara se conecta a un puerto serie del ordenador. En esta conexión, las cámaras son independientes entre sí y una no conoce la existencia del resto. Se refleja esquemáticamente en la figura 3.48 :

Figura 3.48 : Conexión en paralelo de varias cámaras.

Para implementar la conexión entre el ordenador y la cámara, es necesario usar un conector que tenga tanto el conector serie, para conectar al ordenador, como el conector VISCA, que permita conectar a la cámara. Este cable no es suministrado por el fabricante cuando se adquiere la cámara, así que se deberá comprarse aparte o fabricarse a partir de los componentes comerciales sueltos. La implementación del cable es muy sencilla y no requiere de ningún conocimiento especial. Se usará por un lado un conector DB9 hembra, para conectar al puerto serie del PC y un conector VISCA macho para la cámara. para el cable, servirá cualquier cable de 8 hilos. La numeración de los cables en el conector VISCA, sería la que se puede ver en la figura 3.49 :

Figura 3.49 : Numeración de los hilos del conector VISCA.

Para que las señales se transmitan adecuadamente del conector VISCA al DB9, se deben conectar los cables del DB9 siguiendo el esquema de la siguiente figura (Figura 3.50) :



Figura 3.50.

A continuación, se detallará el significado de cada uno de los acrónimos de la señal usada : 1) DTR : preparado para transmitir. 2) DSR : preparado para recibir.

3) TXD : transmisión de datos.

4) GND : tierra.

5) RXD : recepción de datos.

6) GND : tierra.

7) IR OUT : señal de orden desde el mando a distancia.

8) MD Caution : señal de detección de movimiento.

3.2.5.1 Definiciones del protocolo. A lo largo de estos apartados se van a mencionar una serie de elementos con los que el lector quizás no esté familiarizado. para intentar evitar que la lectura se haga tediosa, por la falta de comprensión que puedan suscitar determinadas expresiones, se tratará de explicar el significado de las más comunes : • Mensaje de reconocimiento (ACK): es una señal que la cámara envía al ordenador para

indicarle que se acepta la orden enviada, ya sea un requerimiento de información, una orden de ejecución, etc.

• Dirección : la asignada automáticamente al enviar el mensaje de asignación de dirección.

Puede ser cualquier valor entre 1 y 7. El 0 está reservado para el controlador.



• Paquete : unidad fundamental de comunicación entre el controlador y la cámara. Está compuesto por : una cabecera, de 1 byte de longitud; el mensaje, de hasta 14 bytes; y el final, de un byte, y que siempre será el valor FF (Hexadecimal).

• Almacenes (Socket) : espacios de memoria en la cámara preparados para almacenar

comandos. 3.2.5.2 Composición del mensaje. El punto más importante a la hora de establecer una comunicación entre dos dispositivos es entender el protocolo de comunicación existente entre ellos. Ello implica saber qué se debe mandar, qué se debe recibir y qué se ha de recibir cuando se manda algo. Los mensajes en el protocolo VISCA siempre siguen una estructura fija, con un número fijo de bytes de longitud, 16, y en la que se incluyen una serie de módulos con distintas funciones : I. Encabezamiento (header) : 1 byte. Indica el comienzo de comunicación, e incluye las

direcciones del que manda el mensaje y de quien lo recibe. Puesto que el que manda un mensaje a la cámara siempre es el ordenador (las cámaras no tienen posibilidad de interacción entre sí), el encabezamiento de los mensajes siempre es del tipo 8X, siendo X la dirección del destinatario.

II. Modo de comunicación : 2 byte. Es un código que especifica la categoría de la orden,

de manera que una orden para el control es el modo 01, de petición de información es 09 o para mantenimiento el 00.

III. Categoría del mensaje : 2 byte. Especifica la categoría a la que la orden es aplicable.

IV. Mensaje : lo que resta , hasta 14 bytes. Es la orden que motiva el mensaje en sí. V. Fin de comunicación : 1 byte. Es el código que indica que finaliza el mensaje.

Siempre es FF. Por lo tanto, la forma de un mensaje en el protocolo VISCA siempre es de la forma : [8x 00 ss -- -- -- -- -- -- -- FF] En la figura 3.51, puede verse de forma grafica la composición típica de un mensaje en el protocolo VISCA :



Figura 3.51 : Composición del mensaje en VISCA.

3.2.5.3 Tipos de mensajes. En VISCA existen varios tipos de mensajes, que se pueden clasificar en función de los requerimientos que suponen para el dispositivo de destino del mensaje. Se puede por tanto establecer una clasificación de los mismos : a) Órdenes : son mensajes que, enviados desde el controlador a las cámaras, pueden

requerir información, demandar una acción u otros propósitos. La información de respuesta se almacenaría en la parte correspondiente al mensaje.

b) Mensajes de reconocimiento : es la respuesta que la cámara devuelve al ordenador

cuando la orden que se ha enviado es reconocida. Incluye la dirección de la cámara que ha contestado, el número de socket, la información requerida por la orden si es el caso y por último el final de mensaje. Si el mensaje que se envió es un requerimiento de información, ésta se devuelve inmediatamente. Pero si lo que se envía es una orden, se devuelve una señal de reconocimiento de inmediato y la señal de ejecución de la orden se envía cuando la orden ya se ha cumplido. Algunos ejemplos serían :

Señal de reconocimiento z0 4y FF

Ejecución de orden z0 5y FF Devolución de información requerida z0 50 .... FF

Hay un mensaje que merece mención aparte, que es el que emite la cámara cuando se enciende. Este mensaje es de la forma : z0 38 FF

c) Mensajes de error : cuando la orden no se pudo ejecutar o hubo un fallo en la

ejecución, se devuelve un mensaje de error, en lugar de la señal de reconocimiento. Algunos ejemplos de este tipo serían :



Error de sintaxis z0 60 02 FF Buffer de órdenes lleno z0 60 03 FF Orden cancelada z0 60 04 FF No quedan almacenes en la cámara z0 60 05 FF La orden no se puede ejecutar z0 60 41 FF

d) Mensajes de emisión : se usa este tipo de mensaje para repartir el número de

cámara al comienzo de la configuración. El código de cabecera será el 88 en hexadecimal.

e) Direccionamiento automático : este tipo de mensajes sólo es válido cuando se usa el

tipo de comunicación paralelo. La primera cámara a la que le llega el mensaje se asigna de manera automática la dirección 1 e incrementa esta variable en una unidad, la segunda se asigna la dirección 2, etc. El controlador sabe el número de cámaras conectadas por el valor devuelto.

3.2.5.4 Flujo de información en la transmisión. Cuando el sistema cursa una orden y se emite al conjunto de cámaras conectadas, el proceso de intercambio de información puede variar, según el mensaje sea de un tipo o de otro de los vistos anteriormente. El intercambio de información hace que la iniciativa de actuación pase de un dispositivo a otro. Esto se intentará reflejar en los diagramas que se muestran a continuación : 1) El requerimiento de información es resuelto inmediatamente (Figura 3.52) :

Figura 3.52 : Respuesta a requerimiento de información.

2) La orden es guardada para su posterior ejecución (Figura 3.53) :

Figura 3.53 : Orden almacenada.



3) Devolución de mensaje de error (1) (Figura 3.54) :

Figura 3.54 : Devolución de mensaje de error.

4) Devolución de mensaje de error (2) (Figura 3.55) :

Figura 3.55 : Devolución de mensaje de error.

5) Ejecución de más de una orden : la figura 3.56 muestra como dos comandos están

siendo ejecutados :

Figura 3.56 : Ejecución de más de una orden.

6) Anulación de orden (1) (Figura 3.57) :

Figura 3.57 : Anulación de orden.

7) Anulación de orden (2) : en este caso, se anula la orden antes de que se reciba el

mensaje de fin de ejecución, con lo que el comando ya ha sido ejecutado. No se recibe error de almacén, ya que no existe nada guardado (Figura 3.58) :



Figura 3.58 : Anulación de orden.

8) Transmisión de información continuada, con cancelación (Figura 3.59) :

Figura 3.59 : Transmisión de información continuada con cancelación.

3.2.5.5 Lista de órdenes en VISCA. Por último, se mostrará una lista de las órdenes disponibles en VISCA para la cámara Sony Evi-D31. No son todas las órdenes VISCA disponibles, puesto que el protocolo está diseñado para ser usado en otras cámaras, además de ésta. Pero sí son las órdenes que esta cámara puede enviar y recibir con fiabilidad. Instrucción Tipo Código



Instrucción Tipo Código



Instrucción Tipo Código

Mensajes de petición de información: Instrucción Código Respuesta Significado



Instrucción Código Respuesta Significado

3.3 Conclusiones. En este capitulo se han descrito de manera exhaustiva los componentes del sistema de Percepción artificial, las conexiones que los relacionan y los programas necesarios para su manejo en el ordenador que controla el sistema. Se han mostrado en profundidad los componentes de cada dispositivo en el sistema, de forma que incluso personas no iniciadas en el campo de la visión artificial puedan ser capaces de manejar e incluso llegar a trabajar con el sistema en su estado actual. En el caso de que los nuevos estudiantes que se vayan a hacer cargo del proyecto, todo lo que se necesitaría para poder comenzar a trabajar en el sistema, está en este capitulo. Son las bases mínimas que permiten conocer el sistema, en el punto en el que se encontraba cuando se comenzó este proyecto. Como se ve, el sistema no es excesivamente complicado. Está formado por componentes puramente comerciales, salvo puntuales excepciones. Estas excepciones, como puedan ser cables o algunos elementos de sujeción que necesita el carril para la colocación de los microinterruptores, son elementos corrientes que pueden encontrarse sin ninguna dificultad en cualquier tienda del ramo. Así pues, la implementación de un sistema como el que se muestra, no reviste ninguna dificultad, puesto que también se han descrito las conexiones necesarias para poderlo poner en marcha. Durante la realización de este proyecto, se aprendió absolutamente todo lo que tiene que ver con él, sin ningún conocimiento de partida, salvo los que se pueden adquirir a lo largo de la carrera en el campo de la electrónica en general. Se aprendieron los trucos de electrónica que la implementación de tarjetas comporta, a nivel de soldadura, instalación en equipos, medición de tensiones, etc. En algunas partes de este proceso, se trabajó codo



con codo con personal del Departamento de Electrónica, gente con una gran experiencia en el campo. Ello permitió que se pudiesen adquirir conocimientos de primera mano sobre lo que la práctica de la electrónica significa. Este es un campo al que la carrera de Ingeniería Técnica Industrial, no presta toda la atención que debiera, tanto por falta de tiempo como por falta de recursos. Estos conocimientos serán sin duda valiosos para el futuro ingeniero.


Capítulo 4. Modelización del sistema. La implementación de software es siempre un proceso delicado. El principal problema es que esta complejidad no siempre es tan evidente como en otras obras de ingeniería. En un puente, un edificio, una mina o una carretera, siendo sistemas complejos, sus dificultades son evidentes. No ocurre lo mismo cuando se desarrolla una aplicación, ya que el usuario requiere programas cada vez más sencillos, en los que con apretar un botón se obtenga el resultado deseado, lo cual no hace falta decir que no siempre es tan fácil. Y no hace falta decir que precisamente ése es el mayor reto de un programa informático : Lograr que con sólo pulsar un botón, el usuario obtenga los resultados deseados. Y es que el software, en general, es complejo de forma innata, hasta tal punto que, normalmente, llega a desbordar la capacidad de procesamiento humana. Este proceso se va agravando cuanto más sencillos tienen que ser los resultados obtenidos, como es la tendencia actual del mercado. La necesidad de dar cada vez más facilidades al usuario en el uso de los programas implica que los desarrolladores deben prever más y más situaciones posibles, para lograr que su programa sea lo más versátil y, a la vez, lo más fiable posible. A esto debe añadirse que no siempre se parte de bases de trabajo estables, sino que muchas veces las necesidades del usuario de la aplicación van cambiando mientras se genera el código del programa, lo que obliga a optar por dos soluciones posibles, : Empezar de nuevo, con lo cual el proceso de programación no acabaría nunca; O bien adaptar el código existente a las nuevas necesidades expresadas por el mercado. Ni que decir tiene que la segunda vía es, en realidad, la única vía. Para acometer esa complejidad y la variabilidad de las necesidades finales, se necesita acometer el sistema de manera que permita atacar por diversos puntos cada programa. Eso se hace posible con una adecuada descomposición del trabajo y una ordenación minuciosa de los requisitos imprescindibles del sistema. Son precisamente éstas las metas que se persiguen con el uso del modelado de sistemas. Mediante el modelado de sistemas, se obtiene una descomposición valida de los sistemas, lo que permite aplicar una jerarquía a los mismos, que hace posible decidir cuáles de ellos son imprescindibles en el sistema que se quiere desarrollar y cuáles se pueden obviar sin afectar al conjunto. Asimismo, con el modelado de los sistemas, se obtiene un cierto orden que permite acometer la programación desde varios puntos simultáneamente, favoreciendo el trabajo en equipo.

Modelización del sistema. Iván Ruiz Tejedor

En este capítulo se tratará de introducir brevemente a la modelización de sistemas, paso previo imprescindible a la programación de la aplicación en sí, las motivaciones, los métodos y todo lo que origina este planteamiento. Como se verá, más que un requisito, este punto es una recomendación de cara al futuro. Pero no por ser menos necesaria resulta la modelización un concepto asequible, puesto que requiere de una gran capacidad de abstracción y, sobre todo, de tenacidad, puesto que en algunos momentos puede llevar a la desesperación. 4.1 Necesidad de la modelización. Para ser extremadamente prácticos, valga un ejemplo : la modelización es al software lo que los planos de un edificio son a la construcción del mismo. Es decir, sin un modelo en el que basar la programación, se corre el riesgo de que el programa falle en el momento más inoportuno. Y es que es muy fácil caer en los errores más comunes que se cometen en el mundo de la programación, especialmente si se opta por la vía de la improvisación. Para empezar, es necesario tener muy en cuenta que una buena planificación es insustituible por ninguna otra técnica que se pueda imaginar. Son muy comunes estos tres fallos en el desarrollo de un programa informático [PRESS98] : • Mito de gestión : el hecho de trabajar más horas en un programa, o de poner más gente a

trabajar en ello, no van a arreglar un problema generado por un fallo en la planificación del mismo.

• Mito del cliente : con un esbozo general del sistema es suficiente para empezar a escribir

el programa. • Mitos de los desarrolladores : una vez el programa esta terminado y funciona, el trabajo

del programador ha terminado. Lo único que hay que entregar al cliente es el programa acabado.

Estos tres fallos, son la representación de un problema derivado de la complejidad propia de todos los programas informáticos. Dicha dificultad es inherente al software, principalmente por lo que se puede resumir en cuatro motivos (BOOCH96) : 1) La complejidad del dominio del problema.

- Existe una gran cantidad de requisitos compitiendo entre sí, algunas veces incluso enfrentándose unos con otros. La forma en que se representan estos requisitos, no siempre es clara, recurriéndose al uso de mucho texto, con muy pocos dibujos.

- Desacoplamientos en las necesidades del usuario del sistema y los desarrolladores del mismo, motivado por dificultades de comunicación, distintas perspectivas de los problemas o, simplemente, por no tener claro qué es lo que se quiere.

- Modificación de los requisitos con el tiempo, puesto que una vez mejora la relación y el entendimiento entre usuario y desarrollador, se van llegando a nuevas


Iván Ruiz Tejedor Modelización del sistema.

conclusiones, que obligan a corregir el software y adaptarlo, incluso cuando esto pone en peligro la integridad del mismo.

2) La dificultad de gestionar el proceso de desarrollo.

- Dirigir un equipo de desarrolladores manteniendo la unidad de acción, y la integridad del proyecto no es una tarea fácil que se le pueda encomendar a cualquiera.

- Se deben manejar grandes cantidades de código, generado por distintas herramientas, con lenguajes, normalmente de muy alto nivel, lo que dificulta la previsibilidad del comportamiento del programa. También afecta sobremanera la frecuente practica de reutilizar código y patrones de diseño que aportan funciones a veces perjudiciales para el sistema.

3) El detalle que se puede alcanzar a través de l software.

- Resulta difícil resistir la tentación de empezar desde cero todo el proceso, lo que influiría muy negativamente en los costos del mismo. Es por tanto recomendable valerse (que no copiar) del trabajo realizado por otros programadores, siguiendo estándares fiables y comprobando los resultados dados en usos similares.

4) El problema de caracterizar el comportamiento de sistemas discretos.

- La ejecución de un programa, en el fondo no es más que la transición de un sistema discreto entre diversos estados. Cada uno de estos estados resulta independiente, puesto que usa sus propias variables, necesita su tempo de ejecución, etc. Esto hace que sea necesario diseñar cada estado de forma que su ejecución tenga el mínimo impacto sobre las demás partes del programa.

- La transición entre los estados no puede ofrecer puntos intermedios, cosa que puede generar muchos problemas si no se prevé. Lamentablemente, es casi imposible lograr este punto de manera exhaustiva, puesto que aunque el número de estados sea finito, las posibles combinaciones de las transiciones no lo son, y por tanto, tampoco es posible probar cada una de ellas.

Estos cuatro puntos, que se cumplen en mayor o menor medida en todos los sistemas, sea cual sea su finalidad, hacen que el proceso de creación del software necesite de una determinada planificación, de una modelización del problema, que lo descomponga. Así, se revelan como armas increíblemente poderosas el uso de la descomposición, la abstracción y la jerarquía. La descomposición permite obtener sistemas menores, más asequibles. La abstracción permite agrupar elementos que pueden ser tratados igual en el programa, de forma que no haya que luchar con infinidad de objetos, sino con unos pocos muy generales. Por último, la jerarquía, permite poner un poco de orden en el sistema, para poder trabajar en grupos sin caer en la anarquía. 4.1.1 Fundamentos del modelado de objetos. Existen varias maneras de afrontar la modelización de un sistema, en función del método empleado (Figura 4.1):



• Programación orientada a objetos (POO): es un método de implementación en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas, miembros de una jerarquía de clases unidas mediante relaciones de herencia.

• Diseño orientado a objetos (DOO) : es un método de diseño que abarca el proceso de descomposición orientada a objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y dinámico del sistema que se diseña.

Está orientado a construir un modelo que permita razonar sobre el problema y guiar así la implementación del programa. Se deberán plantear preguntas del tipo ¿Qué clases existen y como se relacionan entre sí? ¿Que mecanismos se utilizan para regular la forma en que los objetos colaboran? ¿Dónde debería declararse y construirse cada clase y objeto? ¿A qué procesador debería asignársele un proceso concreto y para un procesador dado, como deberían planificarse sus múltiples procesos?

• Análisis orientado a objetos (AOO) : es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del domino del problema.

Esta orientado a definir el problema, intentando un mejor entendimiento con el cliente, planteándose preguntas como : ¿Qué comportamiento desea que tenga el sistema? ¿Qué objetos existen en el sistema? ¿Cuáles son las misiones de los objetos para llevar a cabo la implementación del comportamiento deseado?

Figura 4.1 : Formas de modelización.

4.2 Necesidad de la independencia. Otro de los puntos que debe guiar el modelado de un programa es la independencia entre todas sus partes. Esto significa generar pequeños modelos, independientes entre sí, con significado propio y que sean integrables en un todo más complejo. De este modo, lo que



se obtiene en el modelado del sistema es en realidad un conjunto de pequeñas partes, articuladas por una serie de reglas fijas de interacción. Esto resulta indudablemente beneficioso al proceso por dos motivos. Al hacer partes concretas, con significado propio, se evitan las confusiones de una parte a otra, puesto que las barreras son claras, y entendibles por todas las partes del sistema. La independencia garantiza también una cuestión muy importante de cara al futuro. Al hacer partes independientes, se logra que el resultado del programa sea un todo integrado por pequeños módulos que pueden acometer tareas concretas de manera más eficiente, con menor intercambio de información, etc. Esto supone que el día de mañana, una de esas partes puede ser reutilizada, bien en el mismo programa, en otra parte distinta, que realiza otro cometido distinto, o bien en un programa nuevo. Esto supone un ahorro tanto de desarrollo de futuras aplicaciones, como de tiempo para escribirlas, lo que redunda en un menor coste del programa. Y en el caso concreto de este proyecto, considerado como una carrera por etapas, hasta llegar a un desarrollo final, la independencia juega un papel fundamental. En los próximos años los siguientes proyectantes, tendrán que desarrollar nuevos programas que completen el que se ha realizado, añadiendo nuevas funcionalidades. Esto será mucho más difícil si pueden prescindir de partes concretas del programa reutilizando código, o añadir nuevas, sin que por ello el sistema se venga abajo, debido a algo tan poco relevante, por ejemplo como es el estilo de programación (De la misma manera que todo el mundo tiene una letra propia, todos los programadores tiene su manera de escribir los programas). El precio a pagar por esta independencia es un ligero retraso en el tiempo de procesamiento de cada paso, puesto que ya no hay un intercambio de datos real entre los objetos, sino que lo que se pasa de un objeto a otro son mensajes con la ubicación de los datos que necesita el siguiente objeto. No se mueve ni el mensaje ni la información, sino una variable testigo de cada objeto, que recoge la información y la lleva al núcleo. Esto, como ya se dijo, genera un pequeño retraso en el proceso general, pero resulta inapreciable con las velocidades disponibles en el mercado de hoy en día. También hay que tener en cuenta que en el mundo de la informática actual, donde el software libre gana adeptos y mercado a marchas forzadas, ésta es una pequeña pero muy importante colaboración al proceso. Un software libre no sólo significa menores precios de los programas, sino que también garantiza la igualdad y la accesibilidad a los recursos. Por ello, desarrollar programas sobre la base de objetos independientes asegura que el código generado puede ser reutilizado por otros desarrolladores en otras aplicaciones, aumentando los recursos disponibles. 4.3 Introducción a la modelización. A la hora de diseñar cualquier programa, es necesario estudiar cuáles son las características del sistema. Esta tarea en principio puede parecer totalmente irrelevante, pero no es cierto; un buen programa es aquel que se ha desarrollado con un profundo conocimiento previo de todos sus puntos importantes. El modelado es la parte central de todas las actividades que conducen a la producción de buen software. Se construyen modelos para conseguir la estructura y el comportamiento deseado en el sistema, para comprenderlo mejor, para



visualizar su arquitectura y fundamentalmente, para que todos los analistas y programadores puedan comprenderlo a posteriori. Por tanto, un modelo podría definirse de manera sencilla como una simplificación de la realidad. A través del modelado se cubren cuatro objetivos fundamentales : • Visualizar cómo es y cómo se quiere que sea un sistema. • Especificar la estructura o el comportamiento de un sistema. • Proporcionar plantillas de diseño. • Generar documentación entendible universalmente. Por otro lado, existen cuatro principios básicos de modelado : o La elección de qué modelos crear tiene una profunda influencia sobre cómo se acomete

un problema y cómo se da forma a una solución. o Todo modelo puede ser expresado con diferentes niveles de precisión. o Los mejores procesos son lo que están ligados a la realidad. o Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través

de un pequeño conjunto de modelos casi independientes. El enfoque actual de casi todos los lenguajes de programación más usados toma una perspectiva orientada a objetos, donde los bloques principales son los objetos y las clases. Esto genera un modelado de los sistemas donde se aplican, de forma que se une de manera indivisible la programación orientada a objetos con el concepto de modelado (Podría definirse un objeto como “cualquier cosa que puede considerarse como individual, con identidad propia en un sistema”. Igualmente, una clase sería “el conjunto de objetos que tienen unas características similares”). El modelo permite comprender mejor el sistema que se está desarrollando. Para ello, resulta necesario observar el modelo desde varias vistas que se complementen, del mismo modo que el plano de una pieza industrial tiene varias vistas (Planta, alzado y perfiles). Básicamente, con cinco vistas interrelacionadas, podría definirse un sistema orientado a objetos (que serían : Vista de casos de uso, Vista de diseño, Vista de procesos, Vista de implementación y Vista de despliegue), estando cada vista compuesta por un conjunto de diagramas. Las vistas atienden a aspectos concretos del sistema, como se puede ver en la figura 4.2, y los diagramas tienen la función de permitir al desarrollador razonar sobre el comportamiento que tendrá el sistema



Figura 4.2 : Modelado de un sistema.

La programación orientada a objetos y, por tanto, la modelización ha adquirido en los últimos tiempos, una gran importancia simplemente porque ha conseguido dar solución a problemas con mayor o menor complejidad en todos los campos de la vida cotidiana. 4.3.1 ¿Qué es UML? Antes de entrar a ver qué es UML y qué funciones realiza en el modelado, es necesario establecer algunas definiciones [BOOCH96]. 4.3.1.1 Definiciones. 1) Método : es un proceso disciplinado para generar un conjunto de modelos que

describen varios aspectos de un sistema de software en desarrollo, usando alguna notación bien definida.

2) Metodología : es una colección de métodos aplicados a lo largo del ciclo de vida del

desarrollo de software y unificados por alguna aproximación general o filosófica. 3) Notación : es un conjunto de diagramas normalizados que posibilita al analista o al

desarrollado el describir el comportamiento del sistema (Análisis) y los detalles de una arquitectura (Diseño) de forma concreta.

Hay que tener en cuenta que la notación no es un fin por sí misma y el hecho de que sea detallada no significa que todos sus aspectos deban ser usados en todas las ocasiones. La notación no es más que un vehículo para capturar los razonamientos acerca del comportamiento y la arquitectura del sistema.

Las notaciones deben ser lo más independientes posibles de los lenguajes de programación, aunque resulta una ventaja el que exista una equivalencia entre ambos.



Como se verá más adelante estas definiciones tienen su importancia a la hora de clarificar qué es UML y cuales son sus características. 4.3.1.2 Bases del UML. UML (Unified Modeling Language) [CUEVA00] representa la voluntad de todo un sector de la industria informática de hacer las cosas bien. Es el considerado sucesor de la gran cantidad de notaciones destinadas a crear un lenguaje de Análisis Orientado a Objetos y de Diseño Orientado a Objetos que surgió entre finales de los 80 y principios de los 90. Es un lenguaje general, que tiene como propósito unificar todas estas tendencias del Modelado Orientado a Objetos. Surge de unificar principalmente las notaciones de Booch, Rumbaught y Jacobson, e intenta dar una visión más amplia que la de la suma de sus partes. Se definió como estándar por el OMG (Object Managenent Group) en el documento MOG Unified Modeling Language Specification. Combina las notaciones del Modelado Orientado a Objetos, del Modelado de Datos, del Modelado de Componentes y del Modelado de Flujos de Trabajo en un nuevo lenguaje de modelado, puesto que UML no es un método ni una metodología. A mediados de los años 80, existían diversos métodos y técnicas OO, con muchos aspectos en común, pero que utilizaban distintas notaciones. Esto resultaba un autentico inconveniente a la hora del aprendizaje, la aplicación y el uso de herramientas, por la pugna entre los distintos enfoques, y de sus respectivos creadores. Esta falta de unidad hizo evidente la necesidad de una notación estándar, que nació finalmente en el OOPSLA95. Así, la historia del UML puede verse representada en el esquema de la figura 4.3 :

Figura 4.3 : Nacimiento del UML.

El UML, poco a poco, se ha ido imponiendo en el mercado, aparte de por sus evidentes ventajas respecto de otros enfoques, por el peso de los participantes y empresas que lo apoyan. Aparte de los grandes metodistas actuales, detrás de este lenguaje están empresas como Microsoft, IBM, Oracle, Texas Instruments, HP o ICON. La promoción que está



recibiendo UML, junto con el gran índice de aceptación que está teniendo entre los desarrolladores, hace pensar que puede ser el lenguaje de modelado orientado a objetos estándar predominante los próximos años. 4.3.2 Objetos y mensajes en UML. Son conceptos clave del UML, puesto que son la base de la abstracción que requiere el lenguaje. También son los que posibilitan hablar de una independencia de los módulos de programación, ya que con ello lo único que se ven son paquetes de datos, con entidad propia, pero que no son accesibles a todo el mundo. Sólo aquellas entidades que tengan autorización para ver dentro del objeto, podrán entrar y ver o modificar las características del mismo. Todos los demás objetos del sistema estarían trabajando con él desde fuera, sin conocer más de su estructura que lo que el propio objeto quiere que se vea. Así, puede definirse un objeto en UML como la unidad atómica que integra estado y comportamiento, pudiendo caracterizar una entidad física (por ejemplo, un coche) o concepto (por ejemplo, una ecuación matemática). El Modelado de Objetos permite representar el ciclo de vida de los mismos a través de sus interacciones. La representación en UML de un objeto es un rectángulo con un nombre subrayado. Por tanto, un objeto en UML correspondería con la ecuación :

Objeto = Identidad + Estado + Comportamiento

La identidad constituye un identificador único y global para cada objeto dentro del sistema. Es determinada en el momento de la creación del objeto y es independiente de la localización física del objeto, es decir, provee completa independencia de localización. Es independiente de las propiedades del objeto, lo cual implica independencia de valor y de estructura. No cambia durante toda la vida del objeto. El estado está representado por los valores de los atributos. Un atributo toma un valor en un dominio concreto. Evoluciona con el tiempo, aunque algunos atributos pueden ser constantes. El comportamiento agrupa las competencias de un objeto y describe las acciones y reacciones de ese objeto. Las operaciones de un objeto son consecuencia de un estímulo externo representado como mensaje enviado desde otro objeto. El comportamiento se podría asumir como las interacciones que el objeto mantiene con otros objetos de su sistema, los mensajes que envía y que recibe de ellos. Esta muy relacionado con el estado (por ejemplo, no se puede aterrizar un avión si éste está en vuelo). Podría decirse así que un sistema informático puede verse como un conjunto de objetos autónomos y concurrentes, que trabajan de manera coordinada en la consecución de un fin específico. El comportamiento global del sistema se basa pues en la comunicación entre los objetos que lo componen.



Dicha comunicación se establece en la forma de mensajes, que es la unidad de comunicación entre objetos (Figura 4.4). Es el soporte de una comunicación que vincula dinámicamente los objetos que fueron separados previamente en el proceso de descomposición. Un estímulo causará la invocación de una operación, la creación o destrucción de un objeto o la aparición de una señal, se puede decir que el mensaje es la especificación de un estímulo.

Figura 4.4 : Comunicación entre objetos.

4.3.3 Modelado de sistemas complejos. Como ya se advirtió en la introducción de este capitulo, los sistemas que se van a someter al proceso de modelado, son sistemas inherentemente complejos. Dicha complejidad, motivada por su propia naturaleza, tiene que tener sin embargo un cierto orden. En caso contrario no se trataría de un sistema, sino de un conjunto de objetos, sin relaciones coherentes entre sí y, por lo tanto, el proceso de modelado en sí sería una pérdida de tiempo. Como se verá a continuación, el hecho de saber que los sistemas presentan un cierto orden, pese a lo confuso de su estructura, es una ayuda inestimable a la hora de acometer la modelización del sistema. Gracias a este orden, mediante el uso reiterado de determinados métodos, resulta mucho más sencillo llegar a un modelo del sistema de manera rápida. Así pues, en un sistema complejo siempre se van a dar estas propiedades de orden : • Jerarquía : todo sistema se compone de subsistemas que a su vez, se relacionan con sus

propios subsistemas, hasta llegar a una parte ínfima, elemental e irreducible del sistema. • Componentes : todos los sistemas complejos son una agrupación de elementos con

características comunes entre sí. La elección de los componentes de un sistema es cosa del desarrollador, puesto que los elige según su propio criterio.

• Enlaces entre componentes : los componentes del sistema se tienen que relacionar entre

sí para que el sistema tenga algo de sentido. Esas relaciones dependerán de cada par de elementos del sistema.



• Patrones : los sistemas complejos siguen patrones comunes, que permiten que se reutilicen los componentes. Por eso mismo, se suelen encontrar partes comunes en sistemas que aparentemente no tienen nada que ver entre sí.

• Evolución : normalmente, un sistema complejo no aparece por inspiración divina, ni

funciona porque sí. Muy al contrario, suelen ser un desarrollo, llevando un paso más allá otros sistemas más simples que funcionaban previamente en el entorno en que se idearon.

4.3.3.1 Métodos de organización. Puesto que el sistema es complejo, la mayor parte de las veces su estudio requiere una capacidad intelectual fuera del alcance de la mayoría. En tales condiciones, se trataría de tareas poco menos que imposibles. Pero ya se ha demostrado que la modelización es posible si se racionalizan los esfuerzos, para lo cual es necesario disponer de métodos que simplifiquen la tarea de modelar el sistema. Los más potentes de ellos serían : 1) Descomposición : aplicando el famoso lema de “Divide y vencerás”, consiste

básicamente en descomponer el sistema en otros subsistemas más pequeños, que permitan comprender cuales son los objetos que lo forman y las relaciones que existen entre ellos. Conociendo los subsistemas y las relaciones entre ellos, se puede llegar a un modelo del sistema total a través de las partes. La descomposición del sistema puede atender a la estructura del mismo (hablándose entonces de descomposición algorítmica), o bien a las acciones del sistema (en lo que se llama descomposición orientada a objetos)

2) Abstracción : permite ignorar lo que no es esencial en el sistema, llevando a modelos

generalizados e idealizados. Con ello se reduce la complejidad, que es de lo que se trata.

3) Jerarquía : el conocimiento de la jerarquía de un sistema revaloriza la información que

se posee de él, puesto que muestra las relaciones entre los objetos del sistema a través de patrones de interacción (mecanismos). Es el método más potente de los tres, pero también es normalmente el de más difícil aplicación.

Estos métodos servirán para poder establecer los objetos imprescindibles del sistema y las relaciones que los unen. Con esta información se pueden elaborar los diagramas de UML, que darán como resultado las vistas de un modelo del sistema estudiado, con lo que se terminaría el proceso de modelado. 4.3.4 Tipos de diagramas. Como se comentó anteriormente, el modelo de un objeto se compone de varias vistas complementarias, compuestas a su vez por uno o varios diagramas. Cada uno de estos diagramas estudia una perspectiva concreta del sistema. Cuando se consideran todos ellos



en conjunto, el resultado es una visión completa y veraz del sistema estudiado. La complementariedad de los diagramas de UML puede verse representada en la figura 4.5 :

Figura 4.5.

A continuación se describirán brevemente algunos de los diagramas más usados en el modelado de UML [BOGGS02]. Como se dijo, no es necesario usar absolutamente todos los diagramas en todos los estudios de un sistema que se hagan. • Diagrama de casos de uso : es una técnica para capturar información de cómo un

sistema o negocio trabaja actualmente, o de cómo se desea que trabaje. No pertenece estrictamente al enfoque orientado a objeto, sino que es una técnica para la captura de requisitos (Figura 4.6) :

Figura 4.6 Diagrama de casos de uso de “Llamar a un ascensor”.

• Diagrama de secuencia : muestra la secuencia de mensajes entre los objetos en un

escenario concreto. Cada objeto viene dado por una barra vertical, mientras que el tiempo transcurre de arriba abajo. Cuando existe una demora entre el envío y la atención, se puede indicar usando una línea oblicua (Figura 4.7) :



B us c ador S ervidorW eb G es torP aginas B as eDatos

P et ic ion de P agina

P et ic ion de P agina

Com ando S QL

Res ultado

P a g in a e n H TML d in á m ico

P a g in a e n H TML d in á m ico

Figura 4.7 : Diagrama de secuencia de “Buscar en una pagina web”.

• Diagrama de colaboración : son útiles en la fase exploratoria, para identificar los

objetos del sistema. La distribución de los objetos en el diagrama permite ver adecuadamente la interacción de un objeto con los demás. La estructura estática viene dada por los enlaces y la dinámica, por el envío de mensajes por los enlaces (Figura 4.8) :

: Cliente

FrontalMaquina

1: Introducir dinero

Control InternoDispensador

2: Ver precio

Calcular cambio

3:

4: Servir

5: Soltar lata

6: Devolver cambio

Figura 4.8 : Diagrama de colaboración de una maquina de refresco

• Diagrama de estados : representa todos los estados posibles por los que puede pasar un

determinado objeto, incluyendo un estado inicial y otro final. Se puede ver así la evolución de un objeto a lo largo del proceso que se quiere representar (Figura 4.9) :



Figura 4.9 : Diagrama de estados de una ejecución en CPU.

• Diagrama de actividad : es una visión simplificada de lo que ocurre durante la

ejecución de un proceso. Es en realidad una extensión del Diagrama de Estados, sólo que ahora, enfocado primeramente a las actividades. Muestra los pasos del proceso, los puntos en los que se tomarán decisiones, etc. Al igual que el Diagrama de Estados, deberán tener un estado inicial y otro final (Figura 4.10) :

Figura 4.10 : Diagrama de actividad de un desayuno.

• Diagrama de clases : es el diagrama principal para el análisis y el diseño. Presenta las

clases y objetos del sistema con sus relaciones estructurales y de herencia. La definición de una clase u objeto incluye definiciones para atributos y operaciones (funciones y variables de la clase). El trabajo realizado en los Diagramas de Casos de



Uso y de Secuencia y Colaboración aporta información para establecer las clases, objetos, atributos y operaciones (Figura 4.11) :

Figura 4.11 : Diagrama de clases de “Escritura de un texto”.

Quedan otros diagramas, pero no son de tanto calado como los que se han visto hasta ahora. De hecho, algunos de ellos, ni siquiera aportan información relevante del sistema, sino que son un apoyo más a los que se han visto hasta ahora. 4.4 Modelado del sistema. La idea de este apartado no es la de mostrar absolutamente todos los pasos del modelado del sistema, sino intentar ofrecer una vista por encima de cómo se llevo a cabo. Para explicar todos los modelos que fueron necesarios, antes de llegar al modelo definitivo del sistema, y ponerse a trabajar en la programación, sería necesario un curso especial para comprender el manejo de Rational Rose. Rational es una herramienta implementada por Microsoft, enfocada a facilitar el proceso de modelado del sistema. Con esta herramienta se pueden desarrollar distintos tipos de diagramas de manera fácil e intuitiva, a la vez que se asegura que el modelo cumple con los requisitos de UML, puesto que el programa lleva implementadas medidas de control que no permiten crear, por ejemplo, asociaciones imposibles. Además de comprender el uso de Rational para poder explicar el proceso de modelado que se llevó a cabo, hay que tener en cuenta que fue el fruto del trabajo de dos personas durante casi un mes, y con muchos intentos fallidos anteriores. Así que el modelado no es una tarea fácil, ya que requiere paciencia y suspicacia. Intentar explicar las sutilezas que motivan cada uno de los esquemas y cada una de las relaciones del sistema, resultaría una pérdida de tiempo, puesto que no es ése el motivo de este proyecto. Para entender plenamente el proceso de modelización es mucho más recomendable acudir a las múltiples guías que existen, tanto en las bibliotecas como en Internet, muchas de ellas incluso pueden descargarse de forma gratuita [LETEL02].



4.4.1 Planteamiento de requisitos. A continuación, se intentará documentar brevemente el proceso de modelado del programa que se va a crear para el control del carril y la cámara en conjunto. Aunque el sistema esté controlado desde un mismo programa, hay que recordar que no se van a controlar simultáneamente los dos dispositivos. Esto asegura total independencia entre las clases que se usen, puesto que los parámetros que se van a manejar no tienen nada que ver unos con otros.. Para acometer el proceso de modelado, es muy importante antes de nada tener claro qué es lo que se quiere que haga la aplicación. Se debe tomar la posición del usuario de la aplicación y considerar qué funciones se esperan del programa y cuáles van a quedar fuera en beneficio de la rapidez en el resultado. Por eso, el primer paso es un planteamiento de los requisitos del sistema. A la hora de plantearse las funciones que debe tener la aplicación a implementar, éstas son las más básicas : - El sistema debe ofrecer un menú de ayuda. - Debe poder manejarse el carril por un lado y la cámara por otro. - No existirá posibilidad de simultanear ambos. - Existirá la posibilidad de inicializar tanto el carril como la cámara. - La cámara dispone de las posibilidades de autozoom y autofocus. El sistema también debe atender a los requerimientos planteados por el modelado de UML, lo que significa que se debe partir de objetos independientes, pero con significado propio. Y por último, hay que tener en cuenta el planteamiento a largo plazo de la aplicación, puesto que en el futuro se implementará un interfaz gráfico a la misma. Con estas ideas en mente, se pueden plantear como necesarios los siguientes objetos en el diagrama de casos de uso, que será el primer diagrama que deberá hacerse, puesto es el que permite englobar todas las funciones que se quieren implementar en la aplicación : - Un objeto GUI, encargado de ser la interfaz hombre – maquina. Este objeto sólo

almacena la orden, no la interpreta, de forma que el día de mañana se puede sustituir por una interfaz gráfica sin tener que cambiara nada más en el programa.

- Un objeto GestorGUI, que se encarga de ver qué dispositivo es el que se desea mover,

pero sin interpretar de qué tipo de movimiento se trata. Esto permite que en el futuro se puedan añadir más objetos al sistema sin tener que cambiar los planteamientos fundamentales de objeto, sino sólo añadirle la parte que engloba a los nuevos objetos.

- Un objeto GestorCamara, encargado de recibir la orden que se ha mandado, interpretarla

y enviar al objeto adecuado el mensaje de movimiento. Esto permite que el día de



mañana se puedan añadir funcionalidades a la cámara sin tener que modificar todo el programa, sólo añadiendo los nuevos módulos y modificando este objeto.

- Objetos del movimiento de la cámara, especializados en transmitir las órdenes necesarias

la cámara para ejecutar el movimiento indicado por el objeto GestorCamara. Serían : InicializarCamara, MoverACoordenadas, Autozoom y Autofocus.

- Un objeto GestorCarril, que haga lo que GestorCamara hace, pero con el carril. - Este, a su vez, motiva dos nuevos objetos, que son las posibilidades de movimiento que

ofrece el carril : Inicializar y MoverDistancia. 4.4.2 Diagrama de Casos de Uso. Con la información aportada por los requisitos del sistema, ya hay suficiente información para plantear un primer diagrama de casos de uso. En este caso, el aspecto del diagrama sería más o menos el mostrado en la figura 4.12. Hay que decir que el Actor que se ve en el diagrama se refiere al usuario de la aplicación, puesto que se considera que es externo a la aplicación en sí. Por otro lado, se ha interpretado el GestorGUI también como externo porque de hecho no está englobado con ninguna de las otras partes. Como se puede ver en el pseudocódigo, es un elemento externo que interpreta los mensajes y los reenvía al objeto adecuado.

Figura 4.12 : Diagrama de Casos de Uso.

Como se puede ver, en esta vista todavía no es necesario entrar en las diferentes clases, variables o funciones que puede tener el programa, sino que simplemente se trata de hacerse una idea del funcionamiento del sistema.



4.4.3 Diagrama de Clases. Una vea que se ha desarrollado el diagrama de casos de uso, es necesario ir desgranando las posibilidades del programa, profundizando en diagramas parciales de los distintos objetos y de la secuencia de órdenes que ésto sigue. A modo de ejemplo, al final de este capítulo se mostrarán algunos ejemplos de los diagramas que se realizaron en el modelado del sistema. Una vez que se van viendo las posibilidades del sistema y que se van realizando los distintos diagramas, se irán viendo las partes que requieren modificaciones, para lograr unas vistas coherentes del sistema. Ello va llevando a un conocimiento más y más profundo del sistema, hasta lograr llegar a un punto donde se pueden empezar a plantear los objetos de la programación que será necesario crear para lograr el modelo definitivo en el que basar el programa. Es en ese punto cuando se puede empezar a implementar el diagrama de clases que se mostrará en este apartado. Dentro del diagrama de clases, se muestran las clases implementadas para el sistema, con las variables que necesitará cada una de ellas. Como ya se vio, el programa es en realidad una interfaz que permite interactuar al usuario con el sistema, siempre en modo consola. Esto significa que el usuario escribirá una serie de comandos en la consola y pulsar la tecla ‘Enter’ para validarlos y comenzar el proceso. Así que la clase “GUI” es la primera que debe crearse, además de una variable que permita almacenar el valor del comando en memoria, “Comando”. Esta clase deberá tener una función “Ayuda”, que permita desplegar el menú de asistencia si el usuario lo requiere. En caso de que el comando recibido no sea el de la ayuda, se llamará a la función “RecepcionMensaje” (hay que recordar que es mejor no usar las tildes en la codificación del modelo, puesto que si luego se va a generar código, como es una de las opciones de Rational, el lenguaje C++ no se lleva nada bien con ellas) de “GestorGUI”. Por lo tanto, la siguiente clase a implementar es “GestorGUI”. Dentro de la clase, está la función “RecepcionMensaje”, llamada por “GUI”, que a su vez contiene otra función, “ControlComando”. Esta función es la que comprueba que el comando introducido tiene sentido. En caso de que el comando no se corresponda con nada de lo se considera comandos validos, se envía un mensaje de error a “GUI” para que lo muestre al usuario. En tal caso, el programa vuelve a estar controlado por “GUI”, mientras que si el comando es correcto, el sistema llama a la siguiente clase. Esta siguiente clase es “GestorControl”, que tiene la función “RecepcionMensaje”, que es a la que se llamará desde la anterior. Esta clase es la que en el diagrama de casos de uso se represento como el actor “Gestor”. Es la encargada de comprobar el comando introducido en la línea de comandos de “GUI”, para ver sí va dirigido a la cámara o al carril, para lo que se emplea la función “DecidirDestino”. La clase “ControlCarril” es una clase con todas las funciones necesarias para ejecutar los movimientos del carril. Se basa principalmente en partes del programa que desarrolló Collado para el control del carril original (Unicamente se añadió un fichero de cabecera necesario para el control del servicio Tinyport). Lo mismo ocurre con la clase



“ControlCamara” y sus clases derivadas, extraídas en su mayoría del programa desarrollado por Yubero para el control de la cámara Pan-Tilt. Cuando se detecta un comando para la cámara, se llama a la clase “ControlCamara”, que necesitará de varias funciones para poder mover la Pan-Tilt : “ControlCamara”, “CamaraEVI”, “Pantilt”, “Filtro” y “ComunicacionSerie”. Como se observan en el modelo, la clase “ControlCamara” es hija de “Pantilt””, lo que significa que la primera puede usar las funciones publicas y privadas y las variables de la segunda. “ComunicacionSerie”, por su parte, se encarga de crear el dispositivo virtual que permite escribir en el puerto serie, a través del cual se controlan los movimientos de la cámara. “CamaraEvi” contiene funciones que se usarán en la clase “ControlCamara” y para poder usarlas, se necesita también a la clase “Filtro” En la figura 4.13 puede verse el diagrama de clases que se implementó para la aplicación :

Figura 4.13 : Diagrama de Clases de la aplicación.



Quizás sea necesaria en este punto una pequeña aclaración. En el diagrama de clases que se muestra aquí no están incluidas todas las funciones que pueden verse en el programa final. Se trata en ese caso de funciones muy pequeñas, muy limitadas y que no tienen ninguna interacción con el conjunto, por lo que realmente no son una parte del modelo en si, sino una expresión del deseo de programar usando siempre funciones y tratando de no sobrecargar el main de la función. Hay que recordar que el modelo debe se una vista por encima del sistema y no un estudio exhaustivo del mismo 4.4.4 Diagramas de secuencia. Los diagramas de secuencia muestran cuáles son los pasos que va a dar el programa en el cumplimiento de una determinada tarea. Al estar realizado antes de la programación de la aplicación, estos diagramas son extremadamente útiles para el desarrollo de la misma, puesto que muestran una secuencia de tiempo de la ejecución de la aplicación. Al no atender a las clases que llevan a cabo la acción o a como se procesan los datos enviados de un objeto a otro, lo que realmente están mostrando es qué objeto tiene el control en cada momento y la función que tiene que llamarse antes de llamarse a la siguiente. En este caso, se mostrarán los diagramas de secuencia más representativos de la aplicación a modo de ejemplo. 4.4.4.1 Ejemplo 1 : Ejecución de un movimiento del carril. Cuando se da una orden en la línea de comandos para mover el carril una distancia concreta, se produce un diagrama de secuencia como éste. El usuario introduce el comando, que se almacena en memoria y se manda un mensaje de recepción de comando. Se comprueba entonces si el mensaje está dentro de las sintaxis admitidas como correctas, y si la orden esta bien, se lee de nuevo, para ver a qué dispositivo esta dirigida. Una vez se ve que se trata de un movimiento del carril, se envía al gestor de movimientos del carril, donde se traduce el mensaje a los comandos entendibles por el dispositivo. La orden se cursa hacia la tarjeta de control del ordenador, de donde pasa al carril y el programa queda entonces a la espera de la confirmación de que se ha producido el movimiento, devolviendo el control del programa. Puede verse el diagrama en la figura 4.14 :

Figura 4.14 : Diagrama de Secuencia de un movimiento del carril.



4.4.4.2 Ejemplo 2 : Ejecución de un movimiento de la cámara. La acción comienza de nuevo en la consola de la aplicación, donde el usuario introduce un comando. Se almacena la cadena de caracteres introducida y se comprueba su validez. Una vez se sabe que el comando es correcto se busca el destino del mismo y se pasa al gestor de movimientos de la cámara, que lo traduce en las órdenes adecuadas para que la cámara se desplace según lo codificado por el usuario. En la figura 4.15 se puede observar como sería el diagrama de secuencia del comando :

Figura 4.15 : Diagrama de Secuencia de un movimiento de la cámara.

4.5 Conclusiones. En el presente capítulo se ha tratado de introducir al lector al mundo de la modelización de sistemas, con una pequeña muestra introductoria al mismo, que únicamente tiene como fin que sea un poco más entendible la segunda parte del capitulo. En l segunda parte, se ha mostrado muy brevemente como se acometió la modelización de la aplicación, para poder proceder de una forma ordenada a la programación de la misma, a partir de los requisitos que el modelo sugería. No se ha incluido todo lo que el proceso de modelización dio de sí, puesto que para ello sería necesario una introducción al UML mucho más extensa que la que se ha hecho , y tampoco es esa la finalidad de este proyecto. Se han incluido en cambio los puntos más interesantes y reveladores del proceso, que permitan tener una ida general de cómo debe desarrollarse la aplicación. Con la información obtenida en este trabajo se evita perder mucho tiempo en callejones sin salida que el modelo ya revela, y que son más fácilmente corregibles en la vista de diagramas que en el proceso de programación.



Por supuesto, hay que avisar que el proceso de modelado no es de una única dirección, sino que al igual que los planos de las obras “Físicas” (Carreteras, edificios, maquinas, etc.), los modelos de UML también pueden ser modificados, si las necesidades de la programación así lo requieren,. En tal caso, lo único que se necesita es volver al modelo, plantear en el mismo las reformas que se han observado en la programación y replantearlo, para volver a obtener un modelo coherente y que siga cumpliendo con los requisitos que se buscaban con el modelo original. Sin duda, es un trabajo que puede resultar un poco redundante, ya que la programación permite ver directamente si algo es implementable o no, pero como ya se dijo, ese aspecto es fácil de ver en una aplicación pequeña, como es el caso de las que se tratan en este proyecto. En una aplicación más grande acometer el trabajo de programación directamente es una tarea poco menos que imposible por cuestiones de tamaño y de tiempo. Lo que se ha buscado con el modelado de este sistema es más bien intentar mostrar unas buenas pautas de trabajo para el programador que se puede llegar a ser, intentando inculcar unos buenos hábitos, ya que, sin duda, ésto es algo que las empresas están empezando a valorar en los desarrolladores.


Capítulo 5. Programa de control del sistema.

En este capítulo se mostrará el trabajo realizado en el presente proyecto, tanto en las mejoras sobre los programas de control de los dispositivos de los que se disponía anteriormente, como en la elaboración del programa de control integral del sistema. También se mostrarán los problemas surgidos durante la instalación del nuevo sistema operativo en el ordenador de control del sistema, Hissenberg. En este ordenador había que instalar programas que son necesarios para que las aplicaciones de control de los dispositivos puedan correr. Dichos programas, como se verá en los apartados correspondientes, están diseñados para funcionar bajo Windows NT únicamente, lo que requiere nuevos protocolos de instalación en algunos casos, y grandes dosis de paciencia en otros. En cualquier caso, lo que aquí se muestra es el proceso de gestación y el manejo de la aplicación de control integral del sistema. No se detallará en cambio, el código fuente del programa, puesto que resultaría excesivamente tedioso. Por ello, el lector dispone de un apéndice (Apéndice A), donde puede encontrar el pseudocódigo de la aplicación detallado. Si en el capítulo tres se mostraban los dispositivos que componen el sistema, de forma que al término del mismo el lector fuese capaz de poner en marcha un sistema similar partiendo de cero, en éste lo que se intentará es que sea capaz de instalar las herramientas necesarias para que todo el sistema pueda funcionar con normalidad. Siguiendo los procedimientos de instalación de los programas aquí mostrados, cualquier persona con unos conocimientos básicos en el manejo del sistema operativo Windows 2000 puede poner a funcionar este sistema o uno similar. 5.1 Instalación de Windows 2000. Cualquier persona que hoy en día trabaje con ordenadores habitualmente, está al tanto de lo que son los sistemas operativos de Microsoft, la familia Windows. Desde hace varios años, se muestran como el rey indiscutible de los sistemas operativos en el ámbito

Programa de control del sistema. Iván Ruiz Tejedor

doméstico y en gran parte de la industria (si bien hay mercados, como el de los grandes servidores o las aplicaciones críticas, donde se ven desbancados por sistemas más seguros y estables), aunque paulatinamente va perdiendo cuota de mercado por la irrupción de los sistemas operativos de código abierto, como es el caso de Linux. En este caso, Windows 2000 se presenta como la evolución lógica de Windows NT (de hecho, en alguna de las pantallas de la instalación, parece que olvidaron cambiar el nombre, y todavía puede leerse “Windows NT 5.0”). Aúna las grandes ventajas de NT en lo relativo a seguridad y estabilidad con el aspecto y la gestión de dispositivos de Windows98. Esto hace que el sistema sea realmente fácil de configurar, con un mantenimiento realmente sencillo. Con un poco de experiencia en el manejo de los sistemas de la familia Windows, cualquier usuario puede llegar a ser un administrador de estos sistemas, sin necesidad de mucho estudio. La facilidad que tiene el sistema para integrar los dispositivos del equipo en el que se instala, así como la gran cantidad de soporte técnico que hay para el sistema, por ser el más usado del mercado, lo convierten en la herramienta ideal para trabajar. El proceso de instalación de Windows 2000 en un ordenador es un proceso relativamente sencillo, que no requiere de grandes conocimientos, sabiendo que, si no se cometen imprudencias, la mayoría de las veces no surgen complicaciones en el mismo. El ordenador hace la mayor parte del trabajo, pidiéndole al usuario únicamente la información referente a contraseñas y configuración del equipo en una red. Sin embargo, tampoco es recomendable que un usuario completamente novel en el uso del sistema instale el programa sin más apoyos que los que el propio programa le muestre a lo largo de la instalación. La experiencia, o en su lugar un manual de uso del programa [RUSSE00], son elementos imprescindibles para el proceso. No es el propósito ni el deseo de este proyecto convertirse en dicho manual, por lo que no se entrará en los pormenores de la instalación. De lo que se trata aquí es de mostrar la integración de los programas de apoyo a las aplicaciones de control en el nuevo sistema operativo. Así pues, para la instalación es recomendable acudir a alguna de las varias guías que se podrán encontrar en cualquier biblioteca (No hay que olvidar que ser el sistema operativo más usado, también significa ser el sistema sobre el que más documentación hay). Por tanto, baste decir que la instalación requerida para el funcionamiento de los programas es la que el programa toma por defecto, pudiéndose, si se desea, ampliar las opciones a todos los paquetes extra que se quiera. A la hora de ver el equipo necesario para poder instalar el sistema, hay que decir que casi cualquier ordenador personal puede servir para este propósito. El único requerimiento a tener en cuenta es que el equipo tenga potencia suficiente para poder ejecutar Windows 2000. Por ello, se requiere una máquina con al menos un Pentium II 233 MHz, 2 GB de disco duro libres, preferiblemente en una partición arrancable y 32 MB de RAM. Al margen de eso, únicamente tres requerimientos : • El equipo debe tener al menos una bahía ISA libre, para la instalación de la tarjeta de

control del SMCC-01. La mayoría de los equipos nuevos ya no disponen de este tipo


Iván Ruiz Tejedor Programa de control del sistema.

de bahías de 16bits, puesto que han quedado anticuadas frente a las PCI de 32 bits, más rápidas y autoconfigurables.

• Al menos una bahía PCI libre, donde se instalará la Matrox Meteor. Todos los equipos

actuales llevan este tipo de bahías, aunque si el equipo no es tan nuevo, puede tener tanto PCI como ISA, estando todas las PCI ocupadas por otros dispositivos

• Al menos un puerto serie libre, al que conectar el cable VISCA de control de la Pan-

Tilt. Este tipo de puerto, más lento que los actuales USB, está desapareciendo del mercado, dándose el caso de que ya no es nada fácil encontrar un portátil que lo tenga.

Se partirá pues de un sistema operativo recién instalado en el ordenador, en el cual se hayan instalado los controladores necesarios para todos los dispositivos que ordenador pueda llevar (En especial, los arriba mencionados). Una vez llevado a cabo el proceso, será cuando toque instalar el software necesario. En tales condiciones, y después de instalados todos los demás dispositivos, el sistema avisará que ha detectado un dispositivo nuevo que no puede instalar, puesto que no encuentra un controlador adecuado 5.1.1 Instalación de las MIL. Las librerías MIL, como se explicó en el apartado 3.2.4, son un conjunto de utilidades de control que permiten el procesamiento de imágenes por parte de la Meteor. También contiene un controlador para poder instalar la tarjeta en Windows NT. Lamentablemente, Matrox ya no proporciona controladores de esta tarjeta para el Windows 2000, puesto que está desfasada, por lo que hay que usar el de NT. Esto representa un problema, puesto que aunque el sistema funciona, la compatibilidad entre Windows NT y 2000 no es total, como tampoco lo son sus respectivos controladores para un mismo dispositivo. Esto provoca que el controlador disponible para NT en el CD de soporte del fabricante no instale completamente la tarjeta en el sistema. A la larga, como se verá, esto provocara pequeños problemas en el sistema a la hora de lanzar los programas de control. Algunas veces, el sistema será incapaz de cerrar la aplicación de control en ejecución por alguna incompatibilidad en los mensajes. Las librerías MIL vienen en un CD suministrado por el fabricante. La versión disponible es la 5.07, pudiéndose descargar actualizaciones de la pagina web de Matrox si se está registrado. En cualquier caso, con esta versión será suficiente para poner en marcha las aplicaciones disponibles. Así pues, se introduce el CD Matrox Imaging Library, que se autoejecutará y presentará la siguiente figura (Figura 5.1), y en ella se deberán seleccionar los componentes a instalar. La instalación que se hará incluirá el controlador de la Meteor, como se verá a continuación, junto a las librerías para su uso y el Intellicam. Este programa permite conectar con la cámara directamente, además de permitir la captura y el tratamiento de imágenes. Resulta útil para saber si la cámara se encuentra correctamente instalada, por lo que se seleccionarán las casillas que instalarán las MIL y el Intellicam.



Figura 5.1 : Componentes a instalar.

Una vez seleccionados los componentes, se pulsa ‘Proceed...’. La siguiente ventana de diálogo que aparece es la figura 5.2. En ella se muestran los términos de la licencia de los componentes seleccionados para instalar.

Figura 5.2 : Licencia de uso de las MIL.

Posteriormente se deberá seleccionar el directorio donde se quiere que sean instalados los programas seleccionados. Para ello, en una ventana como la de la figura 5.3 se puede seleccionar la ruta que se desee, ofreciendo el programa una por defecto.

Figura 5.3 : Ruta de instalación de los programas.

Debido a que se pretende realizar programas con dichas librerías, en la figura 5.4, se debe seleccionar el compilador que se utilizará. Puede ser el compilador de Microsoft o el de Borland. Puesto que en este proyecto se utilizara Visual C++ para la creación de las aplicaciones, se señala el primero :



Figura 5.4 : Compilador que se usará.

Como el CD de instalación es común para todas las tarjetas digitalizadoras que fabrica Matrox, en la figura 5.5, se deberá elegir la tarjeta que se tiene instalada en el equipo, para que así el programa instale el controlador adecuado. En este proyecto en concreto, se trabaja con una Meteor I.

Figura 5.5 : Selección de la tarjeta digitalizadora.

Una vez seleccionada la Meteor, aparecerá la figura 5.6, en la que se pregunta sobre el tipo de chip de color que lleva la Meteor. La tarjeta cuenta con la posibilidad de ampliar su capacidad de captura de imágenes en color mediante la adición de un chip especial. Sin Embargo, en este proyecto, para el procesamiento imágenes que se va a hacer, basta con trabajar sobre la escala de grises, con lo que el chip de color resulta innecesario. Además, para poder trabajar con imágenes en color, sería necesaria una entrada de información triple, para poder tener el sistema de color RGB por separado, lo que requiere procesar tres veces más información. Puesto que el equipo cuenta con un Pentium II a 350Mhz, en semejante potencia de procesamiento resulta excesiva. Por lo tanto se selecciona la etiqueta de monocromo :

Figura 5.6: Modo de uso por defecto de la tarjeta Meteor.



En la figura 5.7, se deberá seleccionar el formato que utiliza la digitalizadora. En este caso, se trata del M CCIR, es decir, 576 x 768 pixels :

Figura 5.7 : Formato de la digitalizadora.

A continuación, se presenta la figura 5.8. En dicho diálogo se preguntará si se posee un disquete con una versión más actualizada del controlador de la tarjeta que el que se ofrece en el CD, que es la versión 5.07. Caso de no tenerlo, se instalará el controlador para la Meteor MIL–32 versión 5.07A.22.

Figura 5.8 : Posibilidad de instalar controladores más recientes.

Para optimizar la velocidad en el procesamiento de imagen con la digitalizadora, se presentará la figura 5.9. En ella se deberá seleccionar el número de Megabytes de memoria sin paginación que se reservarán para la digitalizadora. Aunque el programa ofrece un valor por defecto dentro de las posibilidades del sistema con el que se trabaja, se ha seleccionado como mejor resultado el reservar 8 Mb.

Figura 5.9 : Cantidad de memoria a reservar.



Como última posibilidad de modificación de los parámetros seleccionados anteriormente, se muestra la figura 5.10. En ella se ve un resumen de todas las características que se han ido seleccionando a lo largo del proceso de instalación. En este momento se puede optar por cambiar cualquiera de ellas, volviendo hacia atrás. O bien, si se acepta lo mostrado, se comienza con la copia e instalación de los archivos.

Figura 5.10 : Resumen de la instalación.

Llegados a este punto, todo el proceso ha funcionado con normalidad y el programa comienza a copiar los archivos del CD. Sin embargo, llega a un punto en el que se verá una pantalla de error como la que se muestra en la figura 5.11 :

Figura 5.11: Error en la instalación del controlador.

Dadas las pocas posibilidades de actuación que se ofrecen en esta ventana, no queda más remedio que aceptar. Posteriormente, se puede comprobar que es un error sin importancia y que no pasa de ahí. El sistema funcionará con normalidad, y el error será la única pega del proceso (este error, sin embargo, no se da en versiones anteriores de las MIL probadas en este equipo, como es el caso de la versión 5.0). Terminado el proceso de la copia de archivos, el sistema tratará de instalar el controlador de la Meteor, cosa que no conseguirá, y por lo que se informará que el controlador no es compatible. Es en este punto cuando hay que recordar de nuevo que el sistema operativo para el que se diseñó el controlador es Windows NT, y no el Windows 2000, sobre el que se está instalando ahora. Esto provoca que la instalación no sea posible, aun cuando el sistema funcionará a la perfección. Si el usuario va al Administrador de Dispositivos del sistema, podrá ver que muestra un dispositivo que no está bien instalado, y que se muestra como “Dispositivo desconocido”. Este dispositivo es la tarjeta Meteor, que, según informa el sistema, no tiene instalados los controladores adecuados. Aunque se intentasen instalar de nuevo desde este programa con los controladores del CD, tampoco se conseguiría, puesto que es un problema de incompatibilidad y no de instalación.



En cualquier caso, ya que la tarjeta funciona correctamente, como se puede observar al lanzar la aplicación de seguimiento del láser, no hay que preocuparse más. Simplemente, hay que tenerlo en cuenta para el momento en el que aparezcan los problemas a la hora de cerrar la aplicación y ésta no responda. 5.1.2 Automatización del servicio Tinyport. Ya se vio en el capítulo 3.18 el proceso necesario para la instalación del programa y también se explicó por qué es tan necesario para poder ejecutar la aplicación de control del carril. Con la nueva seguridad de puertos que incorpora Windows 2000, es necesaria la instalación de un controlador para poder escribir directamente en los puertos del equipo. Y es ésa precisamente la función del programa Tinyport. Este programa estaba disponible en el sistema original, con el inconveniente de que era un programa de tipo shareware, que funcionaba durante 30 días, transcurridos los cuales era necesario registrarse, y pagar un cuota, para poder seguir ejecutándolo. Esto cambió con la última versión del controlador liberada en la red, que ya es de tipo libre, y puede descargarse sin ninguna limitación, siempre que no se destine a fines comerciales o militares. Ello implica que la orden de ejecución del programa que se explicaba en el capítulo 3.1.8, ya no es valida, pasando a ser como ésta otra : tpconfig TipoBus NumeroBus Rango Con idénticos valores para los parámetros a los que se indican en el capitulo 3.1.8. Otro inconveniente que presenta este programa es que no efectúa el lanzamiento automático del controlador, por lo que cada vez que se inicia el ordenador, debe ser arrancado, como si de un programa más se tratase. Esto no sería un problema en sí, si no fuese porque el arranque debe ser en modo consola, es decir, introduciendo el comando descrito en el apartado de instalación del programa, lo cual resulta lento y tedioso. Sin embargo, al igual que en Windows NT existía la posibilidad de automatizar el inicio del servicio, en Windows 2000, también existe esa posibilidad, aunque el proceso es bastante distinto a como se hacía en NT [RUSSE00]. Windows 2000 ya no posee una consola de control de servicios. En cambio, los programas de inicio automático, se tratan en esta versión como dispositivos especiales, no arrancables por el equipo. Esto significa que el equipo los detecta como si fuesen dispositivos especiales, que necesitan ser arrancados por el usuario para entrar en funcionamiento. Al igual que en las versiones anteriores, Windows 2000 ofrece la posibilidad también de automatizar este arranque. El proceso para ello es el siguiente : 1) Si se ha instalado Tinyport en este mismo momento, el primer paso de todos es

reiniciar el sistema. Aunque se pueda comprobar que Tinyport está activado, el sistema no carga el controlador del programa hasta que no se reinicia el equipo.

2) Lo siguiente sería iniciar una sesión con un usuario que tenga privilegios de

administrador del equipo. Si el usuario no tiene derechos de administrador, podrá ver



la pantalla de configuración de los dispositivos, pero el equipo no le dejará cambiar la configuración del sistema.

3) Una vez registrado como Administrador del equipo, en el botón de ‘Inicio’ de la barra

de tareas, se escoge la opción ‘Panel de control’ (Figura 5.12) :

Figura 5.12.

4) En la pantalla que aparece, pinchar dos veces el icono ‘Sistema’. 5) En la ventana siguiente, seleccionar la pestaña ‘Hardware’ y pulsar el botón

‘Administrador de dispositivos’ (Figura 5.13) :

Figura 5.13.

6) Al pulsar el botón, se abrirá el Administrador de dispositivos del sistema, que permite

al usuario ver todos los dispositivos físicos que tiene instalados en el ordenador. En esta pantalla, en el menú extensible ‘Ver’, se deberá seleccionar la opción ‘Mostrar dispositivos ocultos’. (Figura 5.14) :



Figura 5.14.

7) En esta vista, el sistema muestra un icono más, que es el de ‘Controladores que no son

Plug and Play’. Esto se refiere tanto a los programas que tienen inicios automáticos en el sistema, como a programas desinstalados, cuyos controladores no se eliminaron correctamente. Extendiendo este menú podrá verse el servicio Tinyport (Figura 5.15) :

Figura 5.15.

8) Pinchando dos veces el icono de Tinyport, se abrirá el menú de propiedades del

servicio, donde muestra, entre otras cosas, que el dispositivo funciona correctamente. Para poder automatizar el servicio, se deberá seleccionar la pestaña de ‘Controlador‘ (Figura 5.16) :



Figura 5.16 : Propiedades del controlador de Tinyport.

9) En esta nueva vista se verán los detalles relativos al controlador del programa (Figura

5.17). En la caja ‘Estado actual’ puede verse el estado del servicio Tinyport en ese momento. Puesto que todavía no se ha automatizado el servicio en esta sesión, aparecerá como ‘Detenido’. Pulsando en el botón ‘Iniciar’, el servicio se arranca para esta sesión y podría usarse el programa de control del carril con normalidad.

Para automatizar el servicio, en la caja de inicio se puede ver que el Tipo de inicio fijado para este controlador esta en ‘Demanda’. Esto significa que el programa se arranca sólo cuando el usuario lo reclama. Si se pulsa el botón para extender el menú de tipos de inicio, se podrá ver una opción ‘Automático’. Seleccionando esa opción, se consigue que Tinyport se inicie automáticamente cada vez que se inicia una sesión en el equipo. También puede verse otro botón de ‘Detalles del controlador’. Si se pincha, el sistema muestra el controlador asociado al dispositivo que se está automatizando, que en este caso sería una ruta que apunta al archivo Tinyport.sys, colocado en la carpeta ‘Drivers’ de System32. Se selecciona pues esta opción y se pulsa el botón ‘Aceptar’, con lo que el sistema guarda los cambios y se puede uno olvidar ya de iniciar el servicio cuando se quiera usar el programa de control.

5.2 Primeras mejoras sobre los programas existentes. Como se comentó, los programas existentes hasta la fecha para el control del carril tenían el inconveniente común de desplazarse siempre en grados. Si bien en el sistema original esto no representaba un gran problema, por necesitarse movimientos muy cortos, en el presente sistema resultaba ciertamente molesto. Al ser el carril mucho más largo, y pese a



llevar un sistema reductor que acoplaba los movimientos del eje a la nueva longitud, los movimientos que se obtenían para números pequeños no dejaban ver las auténticas posibilidades del sistema. Era pues necesario hacer los cambios que permitiesen manejar el programa con distancias en cm, para poder controlar el carril de manera efectiva. Para ello era necesario cambiar la relación de movimientos en el código y el aspecto grafico de la ventana, para que pudiese ejecutarse el programa con conocimiento de las limitaciones. Para poder cambiar la relación de movimientos se recurrió a distintas medidas de los movimientos del carril, para los distintos valores de grados que se le dieron al programa. Mediante una sencilla regla de tres, se podría saber la equivalencia grados / distancia desplazada. Así pues, se midieron los desplazamientos que el sistema hacía cuando se le daban distintas medidas : 1) Distancia : 100 grados. Desplazamiento : 6 cm.

=⇒= xxcmº1

6º100 0,066. Luego con un grado se desplaza 0,06 cm

2) Distancia : 600 grados. Desplazamiento : 40 cm.

=⇒= xxcmº1

40º600 0,067 cm. Luego con un grado se desplaza 0,067 cm

3) Distancia : -300 grados. Desplazamiento : -20,2 (En sentido opuesto a los anteriores).

=⇒=−

− xxcmº1

2,20º300 0,067 cm. Luego con un grado se desplaza 0,067 cm

Para los resultados dados, se puede tomar el valor medio del desplazamiento que produce un grado, es decir, 0,064 cm. Así pues, se comenzó con la aplicación de control de motores. Al estar realizado en Borland, resultaba mucho más fácil de acometer que las demás, por cuanto tiene muchos menos archivos y es mucho más clara. Para cambiar la relación de movimientos en el programa, sólo es necesario introducir un factor multiplicativo que adapte el movimiento a la nueva medida en la línea del programa donde se hace el cálculo del giro que se debe dar al motor. A continuación, sólo se necesitaría compilar la aplicación, y salvarla con un nuevo nombre. Desgraciadamente, al estar la aplicación base desarrollada con Borland, el compilador de Visual no daba un buen resultado, por lo que se decidió ignorar esta parte y pasar a modificar el programa de control de motores de Collado, ControlVision3D.



En esta aplicación, el proceso a seguir era exactamente el mismo. Simplemente introducir el factor que adaptaba los movimientos de grados a centímetros. Para ello, se necesitaba localizar el punto del programa donde se trataba la cifra que el usuario introducía, para pasarla a grados de giro del motor. En el caso de esta aplicación en concreto, el punto donde se debía introducir el factor era Motor.cpp, y, más exactamente, en la línea 77. En ella el programa coge el dato de la casilla de Desplazamiento, señalada por un puntero, y aplica las operaciones necesarias para poder calcular dicho desplazamiento. Puesto que se trata únicamente de sustituir datos, y no de cambiar nada, se introduce el factor ya multiplicado por el factor que produce el encoder, 4. Por tanto, para que el valor que el usuario introduce en el programa se trate como si fuesen centímetros, se deberá introducir un factor :

1º/0,064 cm = 15,625. Si lo multiplicamos también por el factor introducido por el encoder, daría : 15,625 · 4 = 62,5 Ese es el valor del factor. Después de compilar de nuevo la aplicación, la casilla de Desplazamiento, ya indica valores en cm. Faltará tan solo avisar al usuario de la aplicación, cambiando la ventan del programa, que ahora aparecerá como la que se ve en la figura 5.17, y en la que también se indica el valor máximo que se le puede dar al programa, antes de que se salga la plataforma de la zona de seguridad.

Figura 5.17 : Modificación del programa ControlVision3D.



5.2 Aplicación ControlIntegral. Como colofón del proyecto, se realizó en colaboración con un estudiante Erasmus, una aplicación de control del sistema de Percepción Artificial. Con ella, aunque no se puede realizar todavía el proceso de calibrado de la cámara, por no ser posible un movimiento simultáneo de los dispositivos, sí que es posible tener el control de las dos partes desde una misma aplicación. Esto significa un pequeño paso más hacia la meta del vehículo autónomo. La aplicación, en modo consola, es muy sencilla, con muy pocas opciones disponibles, pero es suficiente, sin embargo, para comenzar el proceso de fusión de los dos tipos de programas de control. Está realizado con el programa Visual C++ de Microsoft [BATES99], lo que garantiza que el programa sea ampliable a modo gráfico en un futuro, puesto que el código fuente seguirá disponible para los estudiantes venideros En la aplicación hay un menú de ayuda que explica al usuario cuáles son las órdenes que hay que introducir para que el sistema haga cada uno de los movimientos disponibles. Con ello se solventa el principal problema de la aplicación en modo texto, que es la dificultad de interacción que hay con el usuario, al no tener éste más información que la que se puede obtener por medio de los menús. Al arrancar la aplicación, pinchando dos veces el icono del programa, como en cualquier otra aplicación, se abre una pantalla negra, con el estándar típico de MS-DOS, en la que aparece una línea de entrada de comandos, donde el usuario debe introducir las órdenes que el sistema debe ejecutar, como la de la figura 5.18. En este punto, conviene recordar que se debe cerciorar de que todos los dispositivos están encendidos, puesto que el programa no puede hacer eso por el usuario.

Figura 5.18 : Vista de la aplicación ControlIntegral.

Una vez arrancado el programa, las órdenes disponibles son :



• AYUDA : llama a la función de ayuda del programa, que muestra en la misma pantalla de la aplicación el menú de ayuda, donde se ven las órdenes disponibles y las sintaxis necesarias para ejecutarlas. En la figura 5.19 puede verse dicha pantalla de ayuda.

Figura 5.19 : Pantalla de ayuda de la aplicación.

• CARRIL INIT : inicializa el carril, llevándolo hasta el microinterruptor de posición

inicial. Al llegar a ese punto la plataforma se para, y el programa queda a la espera de nuevas órdenes.

• CARRIL (DISTANCIA) : mueve el carril la distancia dada entre los paréntesis. Hay que

contar con que la cuenta de la distancia siempre se hace desde el punto de partida del movimiento, y no desde el punto de posición inicial, lo que hace más fácil controlar las distancias movidas. Tras acabar el movimiento, el programa espera más órdenes.

Si el valor es negativo, el carril se desplaza a la izquierda, y si es positivo, a la derecha. En cualquier caso, el programa no lleva ningún tipo de control de la zona de movimientos, por lo que, si el programa recibe una orden que lleva la plataforma fuera de la zona de seguridad, la ejecutará de cualquier modo. Únicamente se detendrá cuando se corte el circuito de emergencia del carril, tras lo cual habrá que poner el carril en funcionamiento de nuevo manualmente.

• CAMARA INIT : lleva el foco de la cámara Pan-Tilt al punto de coordenadas (0,0) de la

misma, tras lo cual el programa queda a la espera de nuevas órdenes. • CAMARA ZOOM : habilita la función autozoom de la Pan-Tilt. • CAMARA FOCUS : habilita la función autofucus de la Pan-Tilt. • CAMARA (GRADOS PAN,GRADOS TILT) : mueve la cámara a las coordenadas dadas

entre paréntesis, con las limitaciones propias de la cámara, es decir, un máximo de +/- 25 grados en pan y +/- 100 grados en tilt. Tras finalizar el movimiento, el programa queda a la espera de más órdenes.



• FIN : cierra la aplicación. El programa está escrito siguiendo el modelo que se obtuvo en el estudio previo, tal y como se comentó en el capítulo 4. Gracias a ello, los próximos estudiantes que tengan que desarrollar nuevas funciones para el programa lo podrán hacer fácilmente, añadiendo los nuevos módulos de programas, con las nuevas clases y modificando únicamente los archivos principales del programa encargados de llamar a las distintas funciones. En cualquier caso, las clases que se emplean en el programa se detallan en el apéndice A de este proyecto. 5.3.1 Transcurso del programa. A continuación se intentará dar una visión del funcionamiento interno del programa. Cuando comienza, lo primero que se hace es cargar la clase ‘ControlIntegral’, puesto que se trata de una aplicación en modo consola. Si se mira el código de esta clase, se podrá ver que no contiene casi nada, puesto que todo el código está generado automáticamente por Visual (Esta es la gran ventaja de esta aplicación : la cantidad de código que genera sin intervención del usuario. El inconveniente es que se obtiene un programa con un código fuente que contiene clases que son propiedad de Microsoft). En cualquier caso, sólo sirve como punto de entrada del programa. Desde el main, se llama a la función ‘GUI’, que representa la interfaz que se está ejecutando. Esta clase es la responsable de controlar lo que ocurre en la línea de comandos y ver si se introduce algo en la misma. En caso de que se introduzca un comando, si no es el de ayuda (en cuyo caso mostraría el menú correpondiente), se almacena en memoria. Cuando el comando se ha introducido, el programa se para, en espera de la clase que lo debe comprobar, ‘GestorGUI’. Lo único que hace esta clase es llamar a la función ‘RecepcionMensaje’, para ver si la línea de comando contiene una orden válida para el programa, sin entrar a ver si es para la cámara o para el carril. Así que lo único que maneja esta función es un punteo a la dirección de memoria donde se ha almacenado lo que se introdujo en la línea de comandos. La función ‘ControlMensaje’ se encarga de ver si la sintaxis de la orden está bien. Si no lo está se destruye el objeto y se devuelve el control a la clase GUI. En caso de ser correcto, se debe crear el siguiente objeto. La clase ‘GestorControl’ es la siguiente en entrar en acción. Lo primero que hace es volver a llamar a la función ‘RecepcionMensaje’, para comprobar esta vez a quién va dirigida la orden introducida. Cuando lee la línea de comando almacenada, puede saber si el mensaje va para la cámara o para el carril. Desde este punto el programa se divide en dos, en función del dispositivo que hay que mover. En función del destinatario, se llama a la clase ‘ControlCamara’ o a ‘ControlCarril’. En el fondo, ambos gestores funcionan más o menos igual. Primero comprueban si la orden almacenada es de inicialización, y si lo es, la ejecutan. En caso de no serlo, se tratará de un movimiento, en cuyo caso habrá que extraer del mensaje la



distancia a mover. Se cargan dichos datos y a continuación se llama a las funciones que deben ejecutarlos. Puesto que cada dispositivo tiene distintas funcionalidades, los gestores de cada uno no son exactamente iguales. Para ver las diferencias concretas lo mejor es leer el pseudocódigo en el apéndice A, en el que se listarán todas las clases, funciones y variables del programa.


Capitulo 6. Conclusiones. El presente proyecto ha servido para acercar esta línea de investigación de la Visión Artificial a su meta final, que es la de crear un vehículo dotado de control autónomo. Se ha tenido que aprender desde cero el funcionamiento de los dispositivos que forman el sistema, así como de los programas necesarios para su funcionamiento, gracias a lo cual se ha podido instruir a otros estudiantes colaboradores, como es el caso del estudiante Erasmus con el que se trabajó en la modelización y desarrollo del programa. Se ha trabajado también mucho en el tema del modelado de sistema, adquiriéndose una experiencia muy valiosa para el futuro, pues es un campo de mayor interés para las empresas desarrolladoras. Este tema, que en principio puede parecer muy difícil, no lo es tanto, visto en perspectiva. Resulta un tema complejo sin duda, pero lo es más por el cambio de mentalidad que supone para un estudiante el pasar de hacer pequeños programas sin aplicación práctica, a hacer programas complejos, que ya sí tienen una finalidad más concreta. Esa es una experiencia que no se puede aprender en las clases de programación que se imparten en la Universidad. Como se dijo, resultará tremendamente valioso a la hora de empezar esta nueva etapa que comienza ahora, como es la búsqueda de un empleo, puesto que los estudios ya están finalizados. El trabajo desarrollado ha permitido también tomar contacto con un campo que sin duda tiene un gran potencial, como es el campo de la programación. En una sociedad como la actual, en la que el ordenador cada día está más presente en la vida cotidiana, el ingeniero electrónico debe ser casi tan buen programador como el informático, puesto que en la práctica ningún proyecto en ingeniería se hace hoy en día sin ayuda de ordenadores. Al desarrollar un programa de control se obtienen los conocimientos prácticos de programación, que son la parte fundamental del aprendizaje. Esto otorga al ahora ya ingeniero una posición de ventaja respecto de aquellos que sólo cuentan con lo aprendido en las clases de la carrera. Los trucos, los buenos hábitos, son cosas que se tienen que aprender de primera mano, puesto que son aspectos de la programación difíciles de enseñar con ningún método.


Conclusiones. Iván Ruiz Tejedor

Por último, el proyecto ha servido para aprender a trabajar en equipo con otros estudiantes, tanto en estrecha colaboración como en el caso del Bert Van Damme, el estudiante Erasmus, como con el resto de compañeros del laboratorio, con los que se ha tenido que convivir, compartiendo recursos, experiencias y conocimientos. Desgraciadamente, en una carrera tan individualista como es ésta, tener la posibilidad de trabajar en equipo es algo que desde luego no es frecuente.


Capítulo 7. Futuras mejoras. Indudablemente, queda mucho por hacer. Como ya se ha dicho, éste no es sino un pequeño paso más hacia el futuro vehículo autónomo de seguimiento de catenarias. Tendrán que ser los próximos estudiantes que se hagan cargo del proyecto los que acometan los nuevos retos que se plantean en este proyecto de cara al futuro. Por un lado, deberá desarrollarse un entorno gráfico para la presente aplicación. Como primer paso, bastaría con intentar que el sistema tuviese una interfaz más amistosa que la que se ha desarrollado en este proyecto, puesto que las limitaciones de entorno en modo consola son evidentes. Esto no significa que se deban añadir de inmediato nuevas funcionalidades. Basta con que el uso de la aplicación no requiera del usuario un conocimiento previo de las aplicaciones. Más adelante, en un siguiente paso de la evolución, se deberán incluir en este entorno gráfico nuevas capacidades de control, además de las existentes. La primera de ellas, sería el poder ejecutar los seguimientos de láser implementados hasta la fecha, puesto que en la aplicación ControlIntegral todavía no es posible. Una vez que se tengan estas herramientas disponibles, tal vez sería el momento de ampliar el campo de validez de la aplicación, haciéndola compatible con más plataformas de trabajo, aparte de la de Windows. Se debería trabajar en el desarrollo de un entorno gráfico que permite el uso de la aplicación en una máquina que sólo tuviese instalado el sistema operativo Linux, lo que otorgaría una gran autonomía al sistema. Para ello se pueden usar los distintos entornos de desarrollo disponibles, como por ejemplo las Qt, sobre las cuales hay abundante información en el departamento, gracias al desarrollo de algunos programas que han hecho anteriores compañeros. Por último, quedaría la inclusión de un segundo motor para el desplazamiento del sistema en las cuatro direcciones. Esto ya sería un resultado más que aceptable para un proyecto de investigación como el que se ha comenzado aquí. Pero no por eso sería el punto final, porque el límite sólo está en la voluntad de los desarrolladores.


Bibliografía. [ALAMO00] JOSE Mª DEL ALAMO RAMIRO. Técnicas de control sobre cámaras Pan-tilt para el seguimiento visual de objetos. PFC0053-00, GVA-FAIS-EUITI-UPM, Madrid, 2000. [BATES99] BATES, J., TOMKINS, T. Descubre Microsoft Visual C++ 6. Prentice Hall, Madrid, 1999. [BOGGS02] BOGGS,W., BOGGS, M. Mastering UML with Rational Rose 2002. Sybex, San Francisco, 2002. [BOOCH96] BOOCH, G. Análisis y diseño orientado a objetos con aplicaciones. 2ª Edición. Addison-Weslwy / Díaz de Santos, 1996. [CUEVA00] CUEVA LOVELLE, J.M. Análisis y Diseño Orientado a Objetos, Cuaderno Nº1. Servitec, Oviedo, 2000. [COLLA00] COLLADO HERNANDEZ, R. Adquisición tridimensional de piezas industriales mediante técnicas de luz estructurada. PFC0055-00, GVA-FAIS-EUITI-UPM, Madrid, 2000 [LETEL02] LETELIER TORRES, P. Desarrollo de Software Orientado a Objetos usando UML. www.dsic.upv.es/~uml/ [LOPEZ88] LOPEZ KRAHE J., POUSSET, P. The Detection of Parallel Straight Lines with the Application of the Hough Transform. 9th International Conference on Pattern Recognition (Rome, Italy), pp. 939-941, Computer Society Press, 1988.

Conclusiones. Iván Ruiz Tejedor

[PRESS98] PRESSMAN, R.S. Ingeniería del software: Un enfoque práctico. 4ª Edición. McGraw-Hill, Madrid, 1998. [RUSSE00] RUSSEL, C., SHARON, C. Guía completa de Microsoft Windows 2000 Server. McGraw-Hill, Madrid, 2000 [YUBER01] JOSE LUIS PEREZ YUBERO. Técnicas de Tracking y Autocalibración. PFC063-01, GVA-ELAI-EUITI-UPM, Madrid, 2001.


Apéndice A. Explicación de la aplicación Control integral. Estas son las clases que se implementaron en el programa ControlIntegral.exe : 1.- ControlIntegral 1.1.- Ficheros de cabecera : #include "StdAfx.h" #include "ControlIntegral.h" Todo lo que se genera en el StdAfx.h lo general el propio Visual. 1.2.- Herencia : Ninguna. 1.3.- Descripción :

Es la clase que sirve de entrada y salida al programa. Contiene la función main. Desde aquí se crea el objeto interfaz de GUI.

1.4.- Funciones y variables : Ninguna. 2.- GUI. 2.1.- Ficheros de cabecera : #include "StdAfx.h" #include "GUI.h" Todo lo que se genera en el StdAfx.h lo general el propio Visual. 2.1.- Herencia : Ninguna. 2.3.- Descripción :

Forma la interfaz hombre – máquina del programa, donde el usuario puede escribir las órdenes. Cuando se da una orden, se crea un objeto de la clase GestorGUI, que se encarga de ella. Esta clase sólo es un intermediario. También soporta la ayuda del programa, y procesa la orden de final, devolviendo el control a ControlIntegral.

2.4.- Funciones miembro : 2.4.1.- GUI 2.4.1.1.- Sintaxis : GUI::GUI()

Apéndice A Iván Ruiz Tejedor

2.4.1.2.- Descripción : Constructor de la clase. Su único cometido es la localización de la dirección de memoria (dinámica) del puntero LineaComando.

2.4.1.3.- Pseudocódigo : Crea el objeto al que LineaComando apunta. 2.4.2.- ~GUI 2.4.1.1.- Sintaxis : GUI::~GUI() 2.4.1.2.- Descripción :

Destructor de la clase. 2.4.1.3.- Pseudocódigo : Borra el objeto al que LineaComando apunta 2.4.3.- Funciones miembro públicas : 2.4.3.1.- Consola.

• Sintaxis : GUI::Consola()

• Descripción : En esta función se pide órdenes al usuario de la aplicación, dándole la posibilidad de introducir comandos. La línea que se introduce se almacena en memoria, y se actúa según sea la orden.

• Pseudocódigo : Pedir un comando Almacenar la línea del comando en memoria. Ver si es el comando de fin del programa. Si lo es, destruir el objeto de la clase GUI, y volver a la clase ControlIntegral. Ver si el comando es de petición de ayuda, y mostrarla si lo es. Si no es ninguno de estos, crear un objeto de la clase GestorGUI, y llamar a la función RecepcionMensaje, y pasarle un puntero a LineaComando.

2.4.4.- Variables miembro privadas : 2.4.3.1.- LineaComando. Donde se almacena la línea de comando leída. 2.4.5.- Funciones miembro privadas : 2.4.5.1.- Ayuda.

• Sintaxis : GUI::Ayuda()

• Descripción : Muestra la ayuda de la aplicación, con las órdenes disponibles.

• Pseudocódigo : Únicamente muestra el mensaje en pantalla, hasta que se pulsa una tecla.

3.- GestorGUI 3.1.- Ficheros de cabecera : #include "StdAfx.h" #include "GestorGUI.h" 3.2.- Herencia :


Iván Ruiz Tejedor Apéndice A.

Ninguna. 3.3.- Descripción :

Es la encargada de revisar la sintaxis del comando introducido, y también que los desplazamientos están dentro de lo posible.

3.4.- Funciones miembro: 3.4.1.- GestorGUI 3.4.1.1.- Sintaxis : GestorGUI::GestorGUI() 3.4.1.2.- Descripción :

Constructor de la clase. 3.4.1.3.- Pseudocódigo : Creación del objeto de la clase. 3.4.2.- ~GestorGUI 3.4.1.1.- Sintaxis : GestorGUI::~GestorGUI() 3.4.1.2.- Descripción :

Destructor de la clase. 3.4.1.3.- Pseudocódigo : Destrucción del objeto de la clase. 3.4.3.- Funciones miembro públicas : 3.4.3.1.- RecepcionMensaje.

• Sintaxis : GestorGUI::RecepcionMensaje(char *LineaComando)

• Descripción : Esta función es llamada desde Consola. A su vez, llama a la función ControlComando, y se actúa en función de lo que de cómo resultado esa función. Cuando se escribe algo correcto en la línea de comandos, se crea el objeto GestorControl, y se llama a su función RecepcionMensaje. Si el comando esta mal, se destruye el objeto.

• Pseudocódigo : Aplicar ControlComando a LineaComando. Si es correcto lo guardado, crear el objeto de la clase GestorControl, y llamar a la función RecepcionMensaje. Si no, destruir el objeto, y volver a la clase GUI.

3.4.4.- Variables miembro privadas : 3.4.3.1.- char *LineaComando. 3.4.5.- Funciones miembro privadas : 3.4.5.1.- ControlComando.

• Sintaxis : bool GestorGUI::ControlComando(char *LineaComando)

• Descripción : Comprueba la sintaxis de LineaComando.

• Pseudocódigo : Comprueba si la orden es para el carril. Si lo es, comprueba si es inicialización o movimiento. Si es alguno de ellos, devuelve Verdadero, y si no, comprueba si es una orden a la cámara.



Si lo es, mira comprueba si es inicialización, movimiento, autozoom o autoenfoque. Si es alguna de estas, devuelve Verdadero, y si no, Falso.

4.- GestorControl 4.1.- Ficheros de cabecera : #include "StdAfx.h" #include "GestorControl.h" 4.2.- Herencia : Ninguna. 4.3.- Descripción :

El mensaje proveniente del GestorGUI, se separa aquí. Si el comando es para el carril, se crea un objeto ControlCarril, y se llama a su función RecepcionMensaje. Si es para la cámara, se crea el objeto ControlCamara, y se llama a su función RecepcionMensaje.

4.4.- Funciones miembro: 4.4.1.- GestorControl 4.4.1.1.- Sintaxis : GestorControl:: GestorControl() 4.4.1.2.- Descripción :

Constructor de la clase. 4.4.1.3.- Pseudocódigo : Creación del objeto de la clase. 4.4.2.- ~GestorControl 4.4.1.1.- Sintaxis : GestorControl::~GestorControl() 4.4.1.2.- Descripción :

Destructor de la clase. 4.4.1.3.- Pseudocódigo : Destrucción del objeto de la clase. 4.4.3.- Funciones miembro públicas : 4.4.3.1.- RecepcionMensaje.

• Sintaxis : void RecepcionMensaje(char *LineaComando)

• Descripción : Llama a la función Decidir. Dependiendo del resultado que de, se crea un objeto ControlCarril o ControlCamara, y se llama a la función RecepcionMensaje de la que sea.

• Pseudocódigo : Llamar a la función Decidir Si devuelve Falso, crear un objeto Carril de la clase ControlCarril. Si devuelve Verdadero, crea el objeto cámara de la clase ControlCamara.

4.4.4.- Variables miembro privadas : 4.4.3.1.- char *LineaComando Es un puntero a la variable LineaComando. 4.4.5.- Funciones miembro privadas :



4.4.5.1.- Decidir. • Sintaxis :

bool Decidir(char *LineaComando) • Descripción :

Comprueba la línea de comando, y en función de si es para el carril o la cámara, devuelve Falso o Verdadero, respectivamente.

• Pseudocódigo : Comprueba si la primera palabra de la orden es ‘carril’. Si lo es, devuelve Verdadero. Si no, comprueba si es ‘cámara’. Si lo es, devuelve Verdadero.

5.- ControlCarril 5.1.- Ficheros de cabecera : #include "StdAfx.h" #include "ControlCarril.h" 5.2.- Herencia : Ninguna. 5.3.- Descripción :

Aquí es donde se hace le movimiento de verdad. Se extraen los datos de LineaComando, y se recodifican de manera entendible, en una estructura que usarán todas las funciones de movimiento del carril.

5.4.- Funciones miembro: 5.4.1.- ControlCarril 5.4.1.1.- Sintaxis : ControlCarril::ControlCarril() 5.4.1.2.- Descripción :

Se inicializan algunos componentes de la memoria dinámica, como pControl, psMiBuffer y psBuffer. Se crea el handle hTPort. Se cargan los valores por defecto de psBuffer y de las variables bTestigoMover, bTestigoGraficas, bTestigoError y fPosicionActual.

5.4.1.3.- Pseudocódigo : Crear los objetos pControl, psMiBuffer y psBuffer. Crear el handle hTPort. Cargar los valores por defecto de psBuffer, bTestigoMover, bTestigoGraficas, bTestigoError y fPosicionActual

5.4.2.- ~GestorControl 5.4.1.1.- Sintaxis : ControlCarril::~GestorControl() 5.4.1.2.- Descripción :

Borra las variables de memoria dinámica declaradas en el constructor. Cierra el handle hTPort.

5.4.1.3.- Pseudocódigo : Borrar psBuffer y pControl. Cerrar el Tinyport.

5.4.3.- Funciones miembro públicas : 5.4.3.1.- RecepcionMensaje.




• Descripción : Esta función se llama cuando un comando de movimiento del carril llega a la clase GestorControl. Extrae los datos del movimiento, y los pone en la estructura psBuffer. Entonces llama a la correspondiente función de movimiento del carril.

• Pseudocódigo : Comprobar si es una inicialización. Si lo es, llamará a la función OnPrincipioCarrera(). Si no, sacar el número de la distancia a mover, ponerlo en psBuffer y llamar a las funciones OnCargarDatos y OnMoverMotor.

5.4.4.- Variables miembro privadas : 5.4.3.1.- fPosicionActual. Para guardar la posición del carril. 5.4.3.2.- struct Buffer.

Tiene las siguientes partes : - int PosicionMotor - int Desplazamiento - float Velocidad - float Aceleracion - int Kp - int Ki - int Kd - int ModoPulso - int OpcionMotor

Se usa para pasar los datos del movimiento del carril de una función a otra 5.4.3.3.- Buffer *psBuffer 5.4.3.4.- Buffer *psMiBuffer Son punteros a la variable Buffer 5.4.3.5.- union Entero char oct[2]; int num; 5.4.3.5.- union EnteroLargo char oct[4]; long num;

Realmente, no serían necesarios, pero ayudan a mantener el control en la función.

5.4.3.6.- struct SCONTROL Tiene las siguientes partes :

- unsigned Direccion - union EnteroLargo pos - union EnteroLargo vel - union EnteroLargo acc - union Entero Kp, Kd, Ki - union Entero il - char T - float pr - float re - union EnteroLargo max_pos - union Entero max_error - char configuracion



- char estado - int i - float pos_des - float vel_des - float ace_des Se usa para pasar datos de una función a otra.

5.4.3.7.- SCONTROL *pControl Puntero a la variable SCONTROL. 5.4.3.8.- char LineaComando Puntero a la variable que almacena la línea de comandos. 5.4.3.9.- handle hTPort 5.4.3.10.- file *hFichero Estas dos variables son necesarias para escribir en la tarjeta de control. 5.4.3.11.- int pdNumDatos 5.4.3.12.- long lMayorDatoDeseada

5.4.3.13.- long lMayorDatoDeseadaAux 5.4.3.14.- long lMayorDatoReal 5.4.3.15.- long lMayorDatoAux 5.4.3.16.- bool bTestigoMover 5.4.3.17.- bool bTestigoGraficas

5.4.3.18.- bool bTestigoError 5.4.3.19.- bool bTestigoParar

Todas estas funciones se usan en las funciones miembro privadas, en el proceso de movimiento

5.4.5.- Funciones miembro privadas : Se detallarán únicamente las tres más relevantes. El resto sólo se comentarán por encima, puesto que son cortas y se explican suficientemente en el código

5.4.5.1.- OnCargarDatos. • Sintaxis :

ContolCarril::OnCargarDatos() • Descripción :

Prepara el movimiento del carril. Pone los datos necesarios en la estructura, inicializa la tarjeta de control, pasa los parámetros al PID, convierte los datos a centímetros y comprueba los errores

• Pseudocódigo : psMiBuffer = psBuffer bTestigoError = false Si no se inicializa, podría provocar algún problema. PosicionMotor = 770 Para poner la dirección del motor a mover. pControl->Direccion = psMiBuffer->MotorPosicion pControl->il.num=LimiteFactorIntegral pControl->T=PeridoMuestreo pControl->max_pos.num=MaximaPosicion pControl->max_error.num=MaximoErrorPosicion pControl->estado=0x02 Se inicializan variables RESET(pControl). Inicializa el LM628



DFH(pControl). Define la posición actual como origen LPES(pControl). Si el error de posición es mayor que el indicado, el 5º bit del registro RDSTAT se pone en alto, y se para el motor pControl->Kp.num=psMiBuffer->Kp pControl->Kd.num=psMiBuffer->Kd pControl->Ki.num=psMiBuffer->Ki parámetros del PID en la tarjeta de control, copiados de pControl LFIL(pControl). Rellena el PID, y el periodo de muestreo. UDF(pControl) Valida los parámetros de PID y el periodo de muestreo. pControl->pos.num=(long)((200.0/360.0)* (ENCODER_LINEAS *62.5*psMiBuffer->Desplazamiento)) Se pasa el dato del movimiento de cm al valor usado por la tarjeta, y se carga en la parte pos.num de pControl. LTP(pControl) pControl->vel.num=(long)(ENCODER_LINEAS*4.0* PERIODO_MUESTREO*1.0/60.0*psMiBuffer->Velocidad*65536.0) Hace lo mismo, pero con la velocidad LTV(pControl) if (psMiBuffer->ModoPulso == 1 ) pControl->acc.num=pControl->vel.num; else pControl->acc.num=(long)(ENCODER_LINEAS*4.0* PERIODO_MUESTREO*PERIODO_MUESTREO*65536.0* psMiBuffer->Aceleracion) LTA(pControl) Actualiza la aceleración. EP(pControl) Control de posición. RSTI(pControl,0xFB) Un cero en los 6 bits menos significativos desactiva el correspondiente indicador de interrupción. if ( bTestigoError == false ) bTestigoMover = true Si no hay errores, mover. if ( bTestigoError == true ) bTestigoError = false; OnCargarDatos(); Si hay errores, no mover y cargar datos de nuevo

5.4.5.2.- OnMoverMotor. • Sintaxis :

void ContolCarril::OnMoverMotor(SCONTROL *pControl) • Descripción :

Movimiento del carril • Pseudocódigo :

Cargar los valores por defecto en bTestigoParar y hFichero. pdNumDatos = 0 Definir la posición actual como origen.



Validar los parámetros de la trayectoria. Cerrar hFichero Llamar a EscribirPosicionActual

5.4.5.3.- OnInicioCarril. • Sintaxis :

void ContolCarril::OnIncioCarril(int Control) • Descripción :

función para la inicialización del carril • Pseudocódigo :

float fIni=0.0 Inicializa la posición actual. if ((inportb32(DIR_PUERTOA) & 0x01 ) == 0x01 ) Inicializa psBuffer. ControlMovimiento() fTiempo=VerTiempoActual() Parada suave Inicialización del indicador de interrupción. Validar los parámetros de la trayectoria else if (control != 0) El motor estaba inicializado.

5.4.5.4.- ControlMovimiento.

• Sintaxis : void ContolCarril::ControlMovimiento()

• Descripción : función usada en la función OnInicioCarril

• Pseudocódigo : Rellena los valores por defecto y la distancia a mover Inicializa el LM628 Define la posición actual como origen Si el error de posición es mayor que el valor indicado, se activa el 5º bit del registro RDSTAT, y se para el motor. Se copian los parámetros del PID de pControl. Se validan, junto con el periodo de muestreo. Se calcula la distancia, en unidades de movimiento para la tarjeta, y se cargan en la parte pos.num de pControl. Se actualiza la velocidad y la aceleración. Control de la posición. Un cero en los 6 bits menos significativos desactiva el indicado de interrupción correspondiente. Define la posición actual como inicial. Valida la trayectoria.

5.4.5.5.- El resto de las funciones (menores), serían : • void ControlCarril::RESET(SCONTROL *SControl)

Inicializa el LM628, mandando el comando Reset, y esperando la respuesta.

• void ControlCarril::EscribeComando(SCONTROL *SControl, char dato )



Espera a que el LM628 esté listo, y escribe datos usando outprtb32 • void ControlCarril::EsperaLM(SCONTROL *SControl)

Espera a que el controlador esté listo, usando funciones declaradas en tiempo

• unsigned char ControlCarril::RDSTAT(SCONTROL *SControl) Lee el estado del controlador con inportb32

• void ControlCarril::outportb32(int portid, unsigned char value) Escribe el dato en el puerto paralelo de 32 bits con WriteByte.

• unsigned char ControlCarril::inportb32(int portid). Lee datos del puerto paralelo de 32 bits. Necesita el hadle hTPort y la función ReadByte

• void ControlCarril::DFH(SCONTROL *SControl) Define la posición actual como origen, usando EscribeComando

• void ControlCarril::LPES(S_ SCONTROL *SControl) Si el error de posición es mayor que el valor indicado, se activa el 5º bit del registro DRSTAT, y se para el motor. SE usan las funciones EscribeComando y EscribeEntero.

• void ControlCarril::EscribeEntero(SCONTROL *SControl, union Entero dato) Escribe un entero en el LM628, escrito en dos usos de outprtb32.

• void ControlCarril::LFIL(SCONTROL *SControl) Almacena parámetros del filtro PID, y el periodo de muestreo, usando EscribeEntero y EscribeComando.

• void ControlCarril::UDF(SCONTROL *SControl) Valida los parámetros del filtro digital y el periodo de muestreo, con EscribeComando

• void ControlCarril::LTP(SCONTROL *SControl) Actualiza la posición con la ayuda de EscribeComando, EscribeEntero y EscribeEnteroLargo.

• void ControlCarril::LTV(SCONTROL *SControl) Actualiza la velocidad con EscribeComando, EscribeEntero y EscribeEnteroLargo.

• void ControlCarril::EscribeEnteroLargo(SCONTROL *SControl, EnteroLargo dato) Escribe un entero largo en el LM628, usando EsperaLM y outportb32

• void ControlCarril::LTA(SCONTROL *SControl) Actualiza la aceleración con EscribeComando, EscribeEntero y EscribeEnteroLargo.

• void ControlCarril::EP(SCONTROL *SControl) Actualiza la posición con EscribeComando, EscribeEntero.

• void ControlCarril::RSTI(SCONTROL *SControl, char dato) Un cero en los 6 bits menos significativos desactiva el indicador de interrupción correspondiente. Usa EscribeComando y EscribeEntero.

• void ControlCarril::STT(SCONTROL *SControl) Valida los parámetros de la trayectoria con EscribeComando.

• void ControlCarril :: EscribirPosAct (float fVar, bool bControl) Modifica la posición actual



• void ControlCarril::STOPAB(struct SCONTROL *SControl) Detiene el motor con la máxima desaceleración

• void ControlCarril::STOPSM(struct SCONTROL *SControl) Para el motor con la desaceleración programada.

6.- ControlCamara. 6.1.- Ficheros de cabecera : #include "StdAfx.h" #include "ControlCamara.h" 6.1.- Herencia : Clase CPanTilt. 6.3.- Descripción :

Base del movimiento de la cámara. El dato llega de la clase GestorControl, y junto con las clases Comunicación, CPanTilt CamaraEVI y el archivo de recursos, se ocupan del movimiento de la cámara

6.4.- Funciones miembro : 6.4.1.- ControlCamara 6.4.1.1.- Sintaxis : ControlCamara::ControlCamara() 6.4.1.2.- Descripción :

Constructor de la clase. En ella se crean los punteros pCamara y pPanTilt. 6.4.1.3.- Pseudocódigo :

Rellenar el puntero a la clase CamaraEVI pCamara y el de la clase CPanTilt, pPanTilt.

6.4.2.- ~ControlCamara 6.4.2.1.- Sintaxis : ControlCamara::~ControlCamara() 6.4.2.2.- Descripción :

Destructor de la clase. También borra las variables pCamara y pPanTilt. 6.4.2.3.- Pseudocódigo : Borrar el objeto de la clase CamaraEVI al que apunta pCamara. Borrar el objeto de la clase CPanTilt al que apunta pPanTilt. 6.4.3.- Variables miembro públicas : 6.4.3.1.- CPanTilt *pPanTilt Puntero a un objeto de la clase CPanTilt 4.4.3.2.- bool m_bTemporizador. Usado en todas las funciones de control de tiempo. 6.4.4.- Funciones miembro públicas : 6.4.4.1.- RecpcionMensaje.


• Descripción : Cuando se da un comando de movimiento de cámara, se llama a esta función desde el GestorControl. Primero, extrae los datos necesarios, y en función del movimiento que es llama a una función o a otra.

• Pseudocódigo : Comprueba si es una inicialización.



Si lo es, rellena los parámetros necesarios, y llama a la función PTDAbsPos. Si no, mira si es un autozoom. Si lo es, llama a la función OnAutozoom. Si no, mira si es un autoenfoque. Si lo es, llama a la función OnAE. Si no, extrae los datos del movimiento Pan y Tilt, y los pasa a las unidades del controlador, inicializa los parámetros necesarios, y llama a la función PTDAbsPos.

6.4.5.- Variables miembro privadas: 6.4.5.1.- double MovPan, MovTilt Para pasar de cm a las unidades que usa el controlador. 6.4.5.2.- char *LineaComando Puntero a la línea de comandos, que se pasa como parámetro. 6.4.5.3.- int m_nAEPrioridad 0=Auto, 1=Manual, 2=Obturador, 3=Iris, 4=Brillo 6.4.6.- Funciones miembro privadas : 6.4.6.1.- OnAutozoom.

• Sintaxis : void ControlCamara::OnAutozoom (void) • Descripción :

Habilita o deshabilita la función autozoom de la cámara • Pseudocódigo :

Llamar a ATAutoZoomOnOff(). 6.4.6.2.- OnAutofocus

• Sintaxis : void ControlCamara::OnAutofocus (void) • Descripción :

Habilita o deshabilita la función autofocus de la cámara • Pseudocódigo :

Lamar a ATAEOnOff().

7.- CPanTilt. 7.1.- Ficheros de cabecera : #include "StdAfx.h" #include "CPanTilt.h" 7.1.- Herencia : Derivada de CDialog, y en la que se basa ControlCamara 7.3.- Descripción :

Clase base de ControlCamara, ya que contiene un gran número de funciones clave para el control de la cámara. Al se una clase públicamente derivada, puede usar tanto funciones públicas como privadas y variables de CPanTilt.

7.4.- Funciones miembro : 7.4.1.- CPanTilt 7.4.1.1.- Sintaxis : CPanTilt::CPanTilt(CamaraEVI *pCam, CWnd *pParent) 7.4.1.2.- Descripción :



Constructor de la clase. Actualiza el valor de m_nPosPan y m_nPosTilt. En ella se crean los punteros pCamara y pPanTilt.

7.4.1.3.- Pseudocódigo : Poner los valores por defecto de m_uchVelocidad, m_nVel y m_nSalto. Llamar a la función PanTiltPosInic 7.4.2.- ~CPanTilt 7.4.2.1.- Sintaxis : CPanTilt::~CPanTilt() 7.4.2.2.- Descripción :

Destructor de la clase. 7.4.2.3.- Pseudocódigo : Borrar el objeto de la clase CPanTilt. 7.4.3.- Variables miembro públicas : 7.4.3.1.- int m_nPosPan Posición Pan. 7.4.3.2.- int m_nPosTilt Posición Tilt. 7.4.3.3.- Unsigned char m_uchVelocidad Velocidad 7.4.3.4.- CamaraEVI *pCamara Puntero a las funciones de CamaraEVI 7.4.4.- Funciones miembro públicas : 7.4.4.1.- DarSalto.

• Sintaxis : Int DarSalto (void)

• Descripción : Muestra el valor del incremento.

• Pseudocódigo : Devolver el valor de m_nSalto.

7.4.4.1.- DarVelocidad. • Sintaxis :

unsigned char DarVelocidad (void); • Descripción :

Muestra el valor de la velocidad. • Pseudocódigo :

Devolver el valor de m_uchVelocidad. 7.4.5.- Variables miembro privadas: 7.4.5.1.- int m_nVel 7.4.5.2.- int m_nSalto Contienen el valor de la velocidad y del salto, respectivamente. 7.4.6.- Funciones miembro privadas : 7.4.6.1.- CambiarDatos.

• Sintaxis : virtual void CambiarDatos (CCambioDatos *pDX)

• Descripción : Llama a la función PTDAbsPos, y le pasa las variables m_uchVelocidad, m_nPosPan y m_nPosTilt.

• Pseudocódigo :



Llamar a PTDAbsPos con los parámetros m_uchVelocidad, m_nPosPan y m_nPosTilt.

7.4.6.2.- OnActualizar • Sintaxis :

afx_msg void OnActualizar (void) • Descripción :

Actualiza la ventana de diálogo. • Pseudocódigo :

Actualizar la ventana. 7.4.6.3.- OnMoverDirecto

• Sintaxis : afx_msg void OnMoverDirecto (void)

• Descripción : Llama ala función PTDAbsPos, y le pasa m_uchVelocidad, m_nPosPan y m_nPosTilt

• Pseudocódigo : Llamar a la función PTDAbsPos, y pasar los datos necesarios.

8.- ComunicacionSerie. 8.1.- Ficheros de cabecera : #include "StdAfx.h" #include "ComunicacionSerie.h" 8.1.- Herencia : Ninguna. 8.3.- Descripción :

Clase para la configuración del puerto serie, para el envío y recepción de datos. 8.4.- Funciones miembro : 8.4.1.- ComunicacionSerie 8.4.1.1.- Sintaxis :

ComunicacionSerie::ComunicacionSerie (dword dwBaudio, byte byExtension, byte byParidad, byte, byBitsParo)

8.4.1.2.- Descripción : Constructor de la clase. Contiene los parámetros del handle de la comunicación serie, y la estructura DCB, con los parámetros del usuario.

8.4.1.3.- Pseudocódigo : Crear el handle.

Ejecutar la función CrearDCB. Poner un cero en el registro de entrada

8.4.2.- ~ ComunicacionSerie 8.4.2.1.- Sintaxis : ComunicacionSerie::~ComunicacionSerie (void) 8.4.2.2.- Descripción :

Destructor de la clase. Cierra el handle del puerto serie. 8.4.2.3.- Pseudocódigo : Cerrar el handle. 8.4.3.- Variables miembro públicas : 8.4.3.1.- handle hPuerto



Representa la entrada del puerto serie, por el que se envían y reciben datos 8.4.4.- Funciones miembro públicas : 8.4.4.1.- ComprobarRecibidos.

• Sintaxis : int ComunicacionSerie::ComprobarRecibidos(void)

• Descripción : Comprueba la cantidad de datos que pueden entrar por el puerto serie

• Pseudocódigo : Llama a la función ComprobarRecepcion, y devuelve su valor de retorno.

8.4.4.2.- LeerDato. • Sintaxis :

unsigned char ComunicacionSerie::LeerDato (void) • Descripción :

Lee y devuelve el dato almacenado en el buffer. • Pseudocódigo :

Llama a la función LeerMensaje. Devuelve uchMensaje.

8.4.4.3.- EscribirDato. • Sintaxis :

void ComunicacionSerie::EscribirDato (unsigned char *uchDato) • Descripción :

Escribe el dato en el buffer • Pseudocódigo :

Llamar a la función EscribirMensaje. 8.4.5.- Variables miembro privadas: 8.4.5.1.- S_COMEST ComEst Estructura que representa el puerto serie. 8.4.5.2.- S_DCB Dcb Estructura para la configuración del puerto. 8.4.5.3.- unsigned char uchMensaje Array de propiedades del mensaje. 8.4.6.- Funciones miembro privadas : 8.4.6.1.- CerrarHandle.

• Sintaxis : void ComunicacionSerie::CerrarHandle ( )

• Descripción : Cierra el handle del puerto serie, y si hay un error, devuelve 0.

• Pseudocódigo : Cerrar el handle Si hay un error, exit(0).

8.4.6.2.- CrearHandle. • Sintaxis :

void ComunicacionSerie::CrearHandle (void) • Descripción :

Crea el handle de comunicación con el puerto serie, y si hay un error, devuelve -4.



• Pseudocódigo : Crear el handle Si hay un error, exit(-4)

8.4.6.3.- EscribirMensaje. • Sintaxis :

void ComunicacionSerie::EscribirMensaje (void) • Descripción :

Manda el byte introducido, a través del puerto serie, y escribe un mensaje de error si falla, en función del error

• Pseudocódigo : Cerrar el handle Si hay error de escritura, exit (-2) Si se prueba a escribir 3 veces sin éxito, exit (-3)

8.4.6.4.- LeerMensaje. • Sintaxis :

void ComunicacionSerie::LeerMensaje (void) • Descripción :

Lee el byte recibido por puerto serie, y da error –1 si hay un fallo • Pseudocódigo :

Leer byte del puerto serie. Si hay un error, exit (-1)

8.4.6.4.- CrearDCB. • Sintaxis :

void ComunicacionSerie::CrearDCB (dword dwBaudios, byte byDimension, byte byParidad, byte byBitsParo)

• Descripción : Configura la estructura que define la comunicación a través del puerto serie según los datos del usuario. Si hay un fallo, da un error de acuerdo a lo que sea.

• Pseudocódigo : Inicializar la estructura DCB. Si no se puede leer, exit (-5). Si no se puede actualizar la estructura, exit(-6).

8.4.6.4.- ComprobarRecepcion. • Sintaxis :

int ComunicacionSerie::ComprobarRecepcion (void) • Descripción :

Comprueba si cdInQue de la estructura m_comStat contiene el valor devuelto con el número de datos que esperan a ser leídos

• Pseudocódigo : Devolver lo que contiene cbInQue Si no se puede acceder, devolver 0

9.- CamaraEVI. 9.1.- Ficheros de cabecera : #include "StdAfx.h"



#include "CamaraEVI.h" 9.1.- Herencia : Ninguna. 9.3.- Descripción :

Representa la cámara, con todas sus funciones de control. 9.4.- Funciones miembro : 9.4.1.- CamaraEVI 9.4.1.1.- Sintaxis : CamaraEVI::CamaraEVI() 9.4.1.2.- Descripción :

Constructor de la clase. 9.4.1.3.- Pseudocódigo : Crear el objeto CamaraEVI.

Crear un objeto pComunicacionSerie. 9.4.2.- ~ CamaraEVI 9.4.2.1.- Sintaxis : CamaraEVI::~CamaraEVI(void) 9.4.2.2.- Descripción :

Destructor de la clase. 9.4.2.3.- Pseudocódigo : Borrar el objeto pComunicacionSerie. 9.4.3.- Variables miembro públicas : 9.4.3.1.- ComunicacionSerie *PuertoSerie Puntero a las funciones que se implementan en la clase ComunicacionSerie. 9.4.3.2.- unsigned char uchMensajeLeido 9.4.3.3.- handel m_Evento. 9.4.4.- Funciones miembro públicas :

Puesto que esta clase contiene un gran número de funciones, sólo se comentarán, mientras que el resto de ellas únicamente se mencionará a título informativo.

9.4.4.1.- void IniciarCamara (void) Manda un mensaje para especificar la dirección de la cámara a iniciar 9.4.4.2.- void setEvent (void) 9.4.4.3.- Colección de funciones de control de la EVI :

• void PowerOn(void) • void PowerOff(void)

9.4.4.4.- Funciones que actúan sobre el zoom : • void ZoomTeleStandard (bool) • void ZoomStop (void) • void ZoomWideStandard (bool) • void ZoomTeleVariable (unsigned char, bool) • void ZoomWideVariable (unsigned char, bool) • void ZoomDirect (unsigned short, bool)

9.4.4.5.- Funciones que actúan sobre el enfoque : • void FocusStop(void) • void FocusFar(bool) • void FocusNear(bool)



• void FocusAutoOn(void) • void FocusManualOn(void) • void FocusAutoManual(void) • void FocusDirect(unsigned short, bool)

9.4.4.6.- Funciones que actúan sobre el autoenfoque : • void AEFullAuto(void) • void AEManual(void) • void AEShutter(void) • void AEIris(void) • void AEBright(void)

9.4.4.7.- Funciones que actúan sobre el brillo : • void BrightReset(void) • void BrightUp(void) • void BrightDown(void)

9.4.4.8.- Funciones que actúan sobre el obturador • void ShutterReset(void) • void ShutterUp(void) • void ShutterDown(void) • void ShutterDirect(unsigned short, bool)

9.4.4.9.- Funciones que actúan sobre el iris : • void IrisReset(void) • void IrisUp(void) • void IrisDown(void) • void IrisDirect(unsigned short, bool)

9.4.4.10.- Funciones que actúan sobre la ganancia : • void GainReset(void) • void GainUp(void) • void GainDown(void) • void GainDirect(unsigned short, bool)

9.4.4.11.- Funciones que actúan sobre el brillo de fondo • void BackLightOn(void) • void BackLightOff(void)

9.4.4.12.- Funciones que actúan sobre los parámetros predefinidos. • void Preset (unsigned char, unsigned char*) • void PresetReset(unsigned char) • void PresetSet(unsigned char) • void PresetRecall(unsigned char)

9.4.4.13.- Funciones para controlar el bloqueo de la cámara. • void KeyLockOff(void) • void KeyLockOn(void)

9.4.4.14.- Funciones relativas al uso del mando a distancia. • void IRReceiveOn(void) • void IRReceiveOff(void) • void IRReceiveOnOff(void) • void IRRecRetOn(void) • void IRRecRetOff(void)



9.4.4.15.- Funciones para conocer el estado de la EVI • bool PowerInq(void)

Si devuelve Verdadero, la cámara está encendida. • int ZoomPosInq(void) • bool FocusModeInq(void)

Si devuelve Verdadero, la cámara se encuentra en modo automático. • int FocusPosInq(void) • int FocusPosInq (int) • int WBModeInq(void) 0=Auto, 1=Interior, 2=Exterior, 3=OnePushMode. • int AEModeInq(void)

Devolverá 0 si está en modo automático, 1 si está en manual, 2 en caso de prioridad para el obturador, 3, en caso de prioridad del iris, y 5 en caso de prioridad del ajuste de brillo.

• int ShutterPosInq(void) • int IrisPosInq(void) • int GainPosInq(void) • bool BackLightModeInq(void)

Si es Verdadero, está activado • int MemoryInq(void) • bool KeyLockInq(void)

Si es Verdadero, está activado • unsigned char IDInq(void) • bool IRReceiveModeInq(void)

Si es Verdadero, está activado • unsigned char VideoSystemInq(void) • int WideConLensInq(void) • int PanTiltModeInq(void) • void PanTiltMaxSpdInq(unsigned char *, unsigned char *) • void PanTiltPosInq(int *, int *) • bool DataScreenInq(void)

Si es Verdadero, está activado • unsigned char AT_MDModeInq(void) • int ATModeInq(void) • int ATEntryInq(void) • unsigned short MDModeInq(void) • void ATObjPosInq(unsigned char *, unsigned char *, unsigned char) • void MDObjPosInq(unsigned char *, unsigned char *, unsigned char *) • unsigned char MDYLevelInq(void) • unsigned char MDHueLevelInq(void) • unsigned char MDSizeInq(void) • nsigned char MDDispTimeInq(void) • unsigned char MDRefModeInq(void) • unsigned char MDRefTimeInq(void)

9.4.4.16.- Otras funciónes : • void WideConLensSet(unsigned char)



• void CommandCancel( unsigned char ) • void PTD1( unsigned char *, unsigned char, unsigned char ) • void PTDUp(unsigned char, unsigned char) • void PTDDown(unsigned char, unsigned char) • void PTDLeft(unsigned char, unsigned char) • void PTDRight(unsigned char, unsigned char) • void PTDUpLeft(unsigned char, unsigned char) • void PTDUpRight(unsigned char, unsigned char) • void PTDDownLeft(unsigned char, unsigned char) • void PTDDownRight(unsigned char, unsigned char) • void PTDSearchTarget(unsigned char, unsigned char) • void PTDStop(void) • void PTDAbsPos(unsigned char, unsigned char, short, short) • void PTDRelPos(unsigned char, unsigned char, short, short) • void PTDHome(void) • void PTDReset(void) • void PTDLimitSet(unsigned char, short, short) • void PTDLimitClear(unsigned char) • void DatascreenOn(void) • void DatascreenOff(void) • void DatascreenOnOff(void) • void ATModeOn(void) • void ATModeOff(void) • void ATModeOnOff(void) • void ATAEOn(void) • void ATAEOff(void) • void ATAEOnOff(void) • void ATAutoZoomOn(void) • void ATAutoZoomOff(void) • void ATAutoZoomOnOff(void) • void ATMDFrameDispOn(void) • void ATMDFrameDispOff(void) • void ATMDFrameDispOnOff(void) • void ATOffsetOn(void) • void ATOffsetOff(void) • void ATOffsetOnOff(void) • void ATAEStartStop(void)



• void ATChase1(void) • void ATChase2(void) • void ATChase3(void) • void ATEntry1(void) • void ATEntry2(void) • void ATEntry3(void) • void ATEntry4(void) • void MDModeOn(void) • void MDModeOff(void) • void MDModeOnOff(void) • void MDFrame(void) • void MDDetect(void) • void ATLostInfo(void) • void MDLostInfo(void) • void MDAdjustY(unsigned char) • void MDAdjustH(unsigned char) • void MDAdjustS(unsigned char) • void MDAdjustD(unsigned char) • void MDRef1(void) • void MDRef2(void) • void MDRef3(void) • void MDRefTime( unsigned char ) • void WBAuto(void) • void WBIndoor(void) • void WBOutdoor(void) • void WBOnePushM(void) • void WBOnePushT(void)

9.4.5.- Funciones miembro privadas : Al igual que antes, solo se detallarán algunas, por ser demasiadas para extenderse.

• int EsperarRespuesta(void) • int LeerMensaje(void)

Compara carácter a carácter lo que se lee, y busca el final de mensaje, devolviendo los datos extraidos

• bool EnviarMensaje(unsigned char *) Establece el protocolo de transmisión con la cámara. Vacía el buffer, manda el mensaje, espera la contestación y cuando llega, la procesa.

• int EscribirMensaje(unsigned char *) Manda los datos uno por uno a la función que los debe pasar al puerto con EscribirDato de ComunicacionSerie.

• void ColocarDato(unsigned char *, unsigned char *)



• void ExtraerDato(unsigned char *, unsigned char *) Coloca o extrae los datos relevantes de una cadena hexadecimal.

• int PasarHexADec(unsigned char *, int) • void TratarError(int)

Encargada de mostrar los mensajes cuando hay un error.


Documents

ADQUISICIÓN DE IMÁGENES MEDIANTE CAMARA PAN · PDF fileadquisiciÓn de imÁgenes mediante camara pan-tilt montada sobre un carro lineal. i. ruiz. 10 de marzo de 2003