CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO … · 2014-02-13 · s.e.p. s.e.i.t. d. gi. t. centro nacional de investigaciÓn y desarrollo tecnolÓgico cenidet esquema para laintegraciÓn

S.E.P. S.E.I.T. D. GI. T.

CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO TECNOLÓGICO

cenidet ESQUEMA PARA LAINTEGRACIÓN DE SISTEMAS DE VISIÓN ROBÓTICA

T E S I S Q U E P A R A O B T E N E R E L G R A D O D E M A E S T R O E N C I E N C I A S E N C I E N C I A S C O M P U T A C I O N A L E S P R E S E N T A : EDSON IGNACIO PERALTAABUNDES

DIRECTOR DE LA TESIS: DR RAÚL PINTO ELÍAS CO-DIRECTOR DE LATESIS: M.C. JOSÉ LUIS GONZhEZ RUBIO SANDOVAL

- CUERNAVACA, MORELOS JÜLfO DE 2003

i

i ,, .).. . . . .

Centro Nacional de Investigación y Desarrollo Tecnológico

C e r z i d e t

Maestría en Ciencias en Ciencias Computacionales

Area de Sistemas Basados en Conocimiento

Tesis

‘‘Esquema para la Integración de Sistemas de Visión Robótica”

Que para obtener el grado de Maestro en Ciencias en Ciencias Computacionales

Presenta

Edson Ignacio Peralta Abundes Número de Control: 69755029

Director de Tesis Dr. Raúl Pinto Elías

Cuernavaca, Morelos

.. d

Julio del 2003

1

A g r a d e c i m i e n t o s ...

Doy gracias a mi Madre que me enseñó a leer y a mi Padre que me inculcó disiplina y responsabilidad.

Agradezco a aquellos Profesores y Maestros que me enseñaron apensar.

Mi sincero agradecimiento al Cenidet que me aceptó y que me abrió las puertas de la superación.

Agradecimientos especiales al Dr. Raúl Pinto, al Dr. Ruiz Ascencio, al Dr. Enrique Sucar, al Dr. Carlos Daniel Garch, al Dr. Gerard0 Reyes por su colaboración y todo el tiempo dedicado en este trabajo.

Agradezco a la SEP y al COSNETpor el apoyo económico a mis estudios.

Un recuerdo a mis compañeros de generación por permitirme compartir y estudiar junto a ellos.

Dedico mi esfuerzo a mi esposa, fuente de mis deceos de superación.

Dedicatoria a mi niño, el mas grande de mis proyectos.

Gracias a Dios por las oportunidades que siembra en mi vida.

i

FORMULARIO C3 REVISIÓN DE TESIS

Cuemavaca, Mor., a 8 de julio de 2003.

Dr. Gerard0 Reyes Salgado Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: Esquema para la Integración de Sistemas de Visión Robótica, realizada por el C. Edson Ignacio Peralta Abundes, y habiendo realizado las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted.

Atentamente

La comisión de revisión de tesis c

Dr. Jose Ruiz Ascencio

I

I

t

C.C.P. Dr. Rodolfo A. Pazos Rangel, Jefe del Depto. de Ciencias Computacionales. Lic. Olivia Maquinay Díaz, Jefe del Depto. de Servicios Escolares. C. Edson Ignacio Peralta Abundes, alumno del programa de maestría.

1‘ I I I

INTERIOR INTERNADO PALMIRA SIN. COL, PALMIRA , A.P. 5-164. CP. 62490. CUERNAVACA. MOR. - MCXICO TELS. 17771 312 23 14. 318 77 4 1 . FAX I7771 312 2434 1 EMAIL pazor~sd-cenidel.com.mx I

.. ,

I"BSEclllluiALXl:hKI*"L

FORMULARIO C4 I (WlTKiKC13" TcccNo:ocIcII

AUTORIZACI~N DE IMPRESI~N DE TESIS

Cuemavaca, Mor., a 14 de julio de 2003.

C. Edson Ignacio Peralta Abundes Candidato al grado de Maestro en Ciencias en Ciencias Cornputacionales Presente

Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la Academia de Ciencias Cornputacionales en relación a su trabajo de tesis: Esquema para la Integración de Sistemas de Visión Robótica, me es grato comunicarle, que confome a los linearnientos establecidos para la obtención del grado de Maestro en Ciencias en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Jefe del Depto. de Ciencias CornpÜtacionales

C.C.P. Lic. Olivia Maquinay Díaz, Jefe Depto. de Servicios Escolares.

INTERIOR INTERNADO PALMIRA S/N. COL. PALMIRA, A.P. 5-164. CP. 62490. CUERNAVACA MOR. - MCXICO TELS. (777)312 23 14.318 77 41. FAX(777) 312 2434 EMAIL [email protected]

ESQUEMA PARA LA INTEGRACIÓN DE SISTEMAS DE VISIÓN ROB~TICA

Resumen

El presente trabajo de tesis se enfoca sobre el estudio de las distintas arquitecturas y

esquemas que existen para lograr la integración entre sistemas de visión artificial

por computadora y sistemas de control de robots articulados. El estudio incluye la

arquitectura tradicional, la reactiva, la .neuro-etolÓgica, la basada en agentes, la

modular y la cliente - servidor. Se propone un esquema de integración basado en el

modelo cliente - servidor y se discuten sus beneficios. El trabajo incluye una

propuesta para la definición de las interfaces de comunicación entre módulos

clientes y servidores especializados en adquirir información visual y en controlar un

robot. Se contempla una revisión de algunos mecanismos computacionales para

realizar la integración entre sistemas y dispositivos especializados en las tareas de

adquisición de información visual o de control y manipulación de robots

articulados. Por Último se define un sistema prototipo para evaluar la adecuación

del esquema de integración propuesto.

La evaluación del prototipo permite apreciar la factibilidad de integrar distintas

aplicaciones de visión artificial y de control de bajo el esquema Cliente - Servidor,

haciendo posible el desarrollo de prototipos de manera rápida y económica, para

una amplía gama de tareas de inspección, reconocimiento, localización y

posicionamiento.

3

ÍNDICE GENERAL

7 1.1 planteamiento del problema 8

I Introducción

1.2 Objetivos 9 1.3 MetodologÍa 10 1.4 Alcance y limitaciones 11 1.5 Plan de exposición 12

2 Estado del arte 13 2.1 Arquitecturas de control 13 2.2 Arquitectura deliberativa o tradicional 14 2.3 Arquitectura reactiva 15 2.4 Arquitectura neuro-etológica 17 2.5 Arquitectura basada en agentes 19 2.6 Arquitectura modular 23 2.7 Arquitectura cliente - servidor 28

3 Esquema de Integración 37

3.1 Arquitecturas y sistemas 37 3.2 Principios de una buena arquitectura 38 3.3 Criterios de evaluación 39 3.4 Esquema conceptual 40 3.5 Sistemas de visión 42 3.6 Servidores de visión 43 3.7 Controlador del robot 46 3.8 Servidores de control 47 3.9 Clientes 49 3.10 Manejo de eventos 50 3.11 Conclusiones 51

4 Znterfaz para Visión 53

4.1 Información visual 53 4.2 Subtareas de los sistemas de vision 54 4.3 Detección de partes. 55

2.8 Conclusiones 36

4

4.4 Orientación de partes. 56 4.5 Determinación del punto de agarre. 56 4.6 Confirmación del punto de agarre. 57 4.7 Inspección. 59 4.8 Determinación del punto de depósito. 62 4.9 Rastreo del punto de depósito en movimiento. 62 4.10 Colocación en la orientación apropiada. 63 4.11 Conclusión 64

5 Interfazpara Control del Robot 65 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10

Características de los lenguajes de robots 65 Funciones de los lenguajes para robots 67 Constantes, variables y otros datos 67 Comandos de movimiento 68 Comandos de efectores 72 Cálculos y operaciones aritméticas 73

Secuencia de control y subruíinas Comunicaciones y procesamiento de datos Comandos en modo monitor 73 Conclusiones 74

73 73

6 Mecanismos de Integración 75 6.1 Integración conceptual 75

6.3 Cliente - Servidor en Windows 80 6.2 Cliente - Servidor en UNIX 78

6.4 Intercambio Dinámico de Datos en Windows 82 6.5 Manejo de Eventos en Java 83 6.6 QNX sistema operativo en tiempo real 85 6.7 Posibles configuraciones 86 6.8 Conclusiones 88

7 Experimentación 90 7.1 Plan de pruebas 90 7.2 Resultados experimentales 92

7.2.1 Comprobación de las interfaces 92 7.2.2 Servidor de visión 93

5

7.23 Calidad técnica 95

7.2.5 Comprobación del prototipo 97 7 3 Conclusiones 99

8 Conclusiones 100

8.1 Conclusiones 101 8.2 Trabajos futuros 102

7.2.4 Comprobación funcional 96

10 I1

12 13

9 Referencias I03

107 111

115

124

Apéndice A: Programas Cliente - Servidor en UNIX Apéndice B: Programa Cliente en Windows Apéndice C: Programas Cliente - Servidor DDE en Windows Apéndice D: Programa Pick and Place

6

CAPÍTULO 1

1 Introducción

El presente trabajo de tesis fue realizado en el Centro Nacional de Investigación y Desarrollo Tecnológico (Cenidet) dentro del grupo de Visión Arafcial del área de Sistemas Basados en Conocimiento, como un esfuerzo por investigar las arquitecturas de los sistemas que integran la percepción visual para el control de robots. La intención que se persigue es definir las bases necesarias para el desarrollo de prototipos de sistemas de visión robótica. Aunque este tipo de sistemas ya ha sido incluso industrializado, actualmente se están desarrollando, a nivel de investigación, arquitecturas de control inteligente que permitan a tales sistemas ser más flexibles, escalables y aptos para responder en tiempo real.

El grupo de visión artificial se prepara para que en un futuro próximo, el Cenidet proponga soluciones de automatización a la industria nacional, así mismo, para capacitar personal que participe en la tarea de automatización. Por ello, este proyecto de tesis se encamina al estudio de las distintas propuestas actuales de arquitecturas de control y arquitecturas inteligentes, donde no sólo tenga que ver la visión artificial, sino con diversos tipos de sensores y actuadores.

7

1.1 Planteamiento del problema

;Por qué incluir visión para cornpiementar el control en la automatización de t a r a ? La utilización de mecanismos sensores permite a un robot interactuar con SU entorno de una manera flexible. La utilización de tecnología sensorial para dotar a las máquinas con un grado de ‘inteligencia’ al tratar con su entorno es realmente un tema de investigación y desarrollo activo en el campo de la robótica. La función de los sensores del robot se puede dividir en dos categorías principales: estado interno y estado externo. Los sensores de estado interno tratan con la detección de variables tales como la posición de una articulación de un brazo, que se utiliza para controlar al robot. Por otra parte los sensores de estado externo tratan con la detección de variables tales como proximidad y contacto. Aunque los sensores de proximidad y contacto juegan un papel significativo en la mejora del funcionamiento, se reconoce que la visión es la capacidad m á s potente del robot [ANGUL01984]:

“La información más completa de que el robot puede disponer, para adaptarse a SU entorno de trabajo y llevar a cabo su misión con el máximo rigor, consiste en la propia imagen del espacio que le rodea”

Por su parte, el Grupo de Visión Artificial del Cenidet cuenta ya con un brazo robot CRS modelo T476’, y se tiene un proyecto para desarrollar un sistema que permita controlarlo mediante percepción visual, es decir, utilizar la visión artificial para realizar la búsqueda y la identificación de piezas, e integrarla con un sistema de control que coordine los movimientos que permitan al manipulador la realización de tareas.

Dicho de esa manera suena muy sencillo. Sin embargo, basta con adentrarse un poco al campo de la robótica, para darse cuenta que tales sistemas resultan complejos, por ser orientados hacia el hardware y por ser dependientes de la tarea para la cual se diseñan, como lo plantea Hager [HAGER1997] :

i Por qué el control mediante visión no es ampliamente usado? Una razón es el hecho que la visión es por sí misma un problema complejo. Para proporcionar información desde la visión al control, la mayoría de los sistemas dependen de algoritmos de procesamiento de imágenes específicos a una tarea, a menudo combinados con hardware especializado. Esto es costoso en términos de tiempo y dinero, ya que obliga al diseñador del sistema a ‘reinventar’ los componentes de visión para cada nueva apücación. Otra difiultad surge de que el posicionamiento o control basado en visión tiende a ser un sistema complejo y dificil de implementar. Problemas tales como la calibración, retardo del tiempo y comunicación entre procesos tienden a ser más difiiles en sistemas de realimentución visual. Finalmente y quizás lo más importante, pocos trabajos se han realizado para hacer que el diseño de los sistemas de control de movimientos basados en viswn sea simple, intuitivo y modular.

’ Consulte la página Web: www.crsroboties.coda465.htm

8

Lo anterior hace notar que si se desea proponer sistemas de control basados en visión como posibles alternativas de automatización, se necesita ser competitivo, esto es, diseñar prototipos en forma rápida y con bajo costo de desarrollo. Para ello hace falta primero, definir una arquitectura de control inteligente2, que facilite diseñar de manera sencilla tales sistemas, un esquema que permita integrar los componentes de visión con los dispositivos de control, de manera que resulte fácil adaptarlos para la ejecución de diversas tareas. De esta problemática surge el actual proyecto de tesis encaminado a definir un esquema para la integración de sistemas de visión robótica.

Se propone como solución al problema planteado, definir las interfaces que permitan la interoperabilidad o el intercambio, tanto entre componentes de visión como entre módulos de control y dispositivos hardware de los robots. En este orden de ideas, se comparte la opinión de Kubitz [KUBITZ1998]:

“Desde el punto de vista de una persona de ciencias computacwnaíes es deseable alcanzar un cierto nivel de abstracción de los recursos (sean sensores o efectores)”.

Para lograrlo Kubitz propone introducir un esquema cliente - servidor para tener abstracción en los accesos a los recursos y permitir un control inteligente. Los detalles del hardware están ocultos en una capa media, que se inserta entre el sistema operativo (servidores que administran los recursos) y las aplicaciones (clientes que controlan el movimiento). El esquema cliente - servidor brinda ciertas ventajas, gracias a su enfoque modular y por capas, tales como la portabdidad, la reusabilidad, la abstracción de los datos, así como facilidades para la prueba y el mantenimiento de los sistemas.

Por Último, se retoma la hipótesis de Hager donde dice que el diseño de los sistemas de control de movimientos basados en visión debe ser simple, intuitivo y modular.

1.2 Objetivos

Lo que se pretende con el actual trabajo de tesis es proporcionar una base que sirva para el desarrollo de prototipos de sistemas de robots controlados mediante percepción visual, bajo un marco de trabajo que facilite un diseño modular, reutilizable e interoperable.

Los autores citados hacen referencia a términos como arquitecturas de control, arquitecturas de Inteligencia Artificial (AI architectures), sistemas de control o control inteligente.

9

Los objetivos que se plantean dentro de proyecto de tesis se definen a continuación:

1. Definir la arquitectura y de las interfaces necesarias para la integración de sistemas de visión y el control de robots manipuladores. I

2. Desarrollar un prototipo de prueba que permita mostrar la integración de sistemas de visión con robots manipuladores, donde los componentes de visión y control del manipulador sean independientes e intercambiables.

3. Probar la hipótesis de que el diseño de sistemas de visión robótica puede ser modular y de manera general, independiente de la tarea.

Como consecuencia de los objetivos planteados se pretende con este trabajo:

4. Proporcionar para el área de Sistemas Basados en Conocimientos del Cenidet una base para el diseño y desarrollo de prototipos de sistemas de control de mediante percepción visual.

5. Definir un esquema general para la integración de sistemas de visión robótica, buscando un enfoque de independencia de la tarea a realizar por el sistema.

1.3 Metodología

La metodología que sigue el presente trabajo, comprende el desarrollo de las siguientes actividades, encaminadas a la consecución de los objetivos propuestos:

1) Estudio y análisis del estado del arte en el campo de los mecanismos de integración de sistemas de visión artificial y sistemas de control de robots. Como producto de esta actividad, se obtendrá un documento acerca del estado del arte sobre arquitecturas de control robot mediante percepción ViSUal.

2) Diseño del esquema o arquitectura de integración visión - control - robot. Como resultado de esta actividad se obtendrá un documento con un diseño modular para la integración de sistemas de control de robots mediante percepción visual, la definición de los componentes, las interfaces para la realimentación o retroalimentación visual, las interfaces para el control del posicionamiento del robot, y el lenguaje o protocolo a utilizar para la programación de las tareas.

10

3) Desarrollo de un sistema de posicionamiento mediante realimentación visual, basado en la arquitectura que se defina en el paso 2. El producto resultante será el código de un sistema prototipo que integre los componentes de visión y control de posicionamiento de un robot manipulador.

4) Diseño de un plan de prueba de la integración. De esta actividad se espera un documento donde se especifiquen las pruebas funcionales y de integración para la validación de las interfaces y los componentes del prototipo.

5 ) Validación del sistema y de la arquitectura de integración. En esta actividad serán documentados los resultados de las pruebas que se realicen.

1.4 Alcance y limitaciones

El presente trabajo de tesis tiene como alcance, la definición de los siguientes elementos:

1) Las interfaces necesarias para proporcionar información visual a los módulos de software que realicen el “control inteligente”.

2) Las interfaces necesarias para controlar la posición de un robot manipulador, por medio del “control inteligente”.

3) El estudio de los mecanismos de integración de sistemas visión - robot (arquitecturas de control mediante percepción visual).

4) El diseño de un esquema (arquitectura) que describa la integración de los componentes de visión y control del robot.

5) El desarrollo de un sistema prototipo que permita integrar componentes de visión y dispositivos de control, basado en el esquema que se defina.

Así mismo, este trabajo de tesis tiene como limitaciones los siguientes puntos:

1) No será considerado el tiempo de respuesta como factor crítico, pudiendo ser escalado si lo permiten las equipos y herramientas disponibles.

2) Los objetos a manipular por el robot serán piezas geométricas conocidas, estáticas, sin traslapes ni contactos, con posiciones aleatorias dentro de un espacio de trabajo restringido y libre de obstáculos.

3) El dominio de las tareas encomendadas al robot manipulador estará restringido al posicionamiento de los objetos que se encuentren en el espacio

0 3 - 0 2 9 7 - 11

de trabajo, de acuerdo a los requerimientos de las relaciones espaciales de los objetos, donde tales requerimientos serán definidos por medio de comandos a nivel de tareas.

Debe hacerse notar que el objetivo principal es definir una arquitectura que permita integrar de manera modular y con independencia al hardware, a sistemas de visión artificial para el control de robots.

1.5 Plan de exposición

El trabajo de tesis se compone de ocho capítulos organizados de la siguiente manera. En el capítulo dos se analiza el estado del arte sobre las arquitecturas para el control de robots mediante percepción visual.

El tercer capítulo contiene el esquema de integración que se propone como arquitectura para el desarrollo de sistemas para el control de robots manipuladores mediante percepción visual. Los capítulos cuatro y cinco incluyen, respectivamente, la definición de las interfaces propuestas para realizar la realimentación visual y el control. El capítulo seis analiza los mecanismos de integración de sistemas que pueden ser empleados para desarrollar aplicaciones que realicen tareas de control de posicionamiento en robots articulados.

Dentro del capítulo siete se presenta el desarrollo de un prototipo que integra la percepción visual con el control de un robot manipulador para la ejecución tareas de control de posicionamiento sobre el robot articulado CRS modelo T476, además presenta el plan de pruebas para la validación del prototipo y los resultados de la evaluación del esquema de integración propuesto.

El capítulo ocho presenta las conclusiones de las pruebas reaüzadas al prototipo, el análisis de los pros y los contras del esquema de integración propuesto y comentarios sobre las áreas de su posible aplicación.

Se anexa en el Apéndice ‘A’ el código fuente de programas cliente y servidor, utilizando sockets en UNM como mecanismo de integración. En el apéndice ‘B’ se describe un programa cliente, usando sockets en Windows como mecanismo de integración. El apéndice ‘C’ presenta los módulos cliente y servidor desarrollados para el prototipo, empleando el protocolo DDE de Windows como mecanismo de integración.

Por último se presenta la bibliografía general consultada para la realización de esta tesis.

12

CAPÍTULO 2

ESTADO DEL ARTE

2 Estado del arte

En este capítulo se exponen y discuten los trabajos más representativos relacionados con este trabajo de tesis, con la finalidad de mostrar las tendencias actuales sobre la investigación y desarrollo de arquitecturas de control para robots. Los trabajos de los autores aquí presentados se consideraron, después de revisar el esquema de acopio proyectado para esta tesis, como las propuestas más representativas del estado del arte.

Los artículos que servirán como referencia en esta tesis y que se expondrán a continuación son:

A. “Arquitecturas de control para robots móviles” [JIMÉNEZ1998] B. “SodaJack: an Architecture for Agents that Search for and Manipulate

C. “A Modular System for Robust Positioning using Feedback from Stereo

D. “Client-Server-Based Mobile Robot Control” [KüBITZ]

Objects” [GEiB19941

Vision” [HAGER1997]

2.1 Arquitecturas de control En el primer artículo se exponen las arquitecturas deiiberativa o trudicwnal, reaetiva y neuro-etológica, las cuales representan sólo algunas de las numerosas arquitecturas modernas actualmente en investigación, con la intención de mostrar la evolución y el avance en la construcción de robots autónomos e inteligentes.

Para Jiménez y Espinosa [JIMÉNEZ1998], una arquitectura para robots comprende el sofrware y el hardware involucrado en el control del robot:

li

13

“una arquitectura queda establecida cuando se consigue realizar una absiracción del hardware subyacente en términos de la definición de una máquina virtual o modelo de programación”.

Aunque dentro del artículo los autores se refieren al campo de la robótica móvil, se considera que las arquitecturas se aplican del mismo modo a robots manipuladores y robots en general.

7

Obtención e Modelado S interpretación de del mundo

e + n

datos -

S O

r e Planeación del Control S movimiento motriz

L_

2.2 Arquitectura deliberativa o tradicional

Durante los años de 1970 a 1985, el desarrollo de robots “inteligentes” se basó en la arquitectura tradicional donde se usaban técnicas clásicas de la inteligencia artificial, las cuales manipulan por medio de símbolos a los datos recibidos de los sensores, realizando una descripción del mundo y la planeación de una ruta libre de colisiones [JIMÉNEZ1998]. La figura 2.1 muestra sus componentes básicos.

Figura 2.1. Arquitectura deliberativa (tradicional)

Dentro de una arquitectnra deliberativa (tradicional) la operación de un robot se implementa en niveles jerárquicos que incluyen un planeador, un navegador y un piloto. El planeador especifica la ruta que seguirá el robot, por medio de un mecanismo de búsqueda (generalmente el algoritmo ‘A estrella’ o ‘A“’) que incluye la posición inicial (xi, yi, e¡) y la posición final deseada (xf, yf, Of), el conocimiento a priori de los obstáculos conocidos, las restricciones existentes, y el tiempo destinado para la misión. El navegador divide la ruta en segmentos y determina el movimiento que se debe realizar. En este nivel también se pueden evitar obstáculos que se detecten por medio de los sensores. Finalmente, el piloto sigue la ruta impuesta por el navegador incorporando el tiempo, lo que determina la trayectoria que el robot seguirá, así como la dinámica asociada a ésta. El piloto envía señales al hardware para activar los actuadores y adquirir datos de los sensores.

14

Una de la ventajas de la arquitectura tradicional es que se tiene información global con la cual elaborar una representación interna del mundo. De esta manera se espera obtener mejores resultados que cuando se toman decisiones basadas en información local. Para una planeación confiable se necesita exactitud en el modelado del mundo, sustentada en sensores de alta precisión y una calibración cuidadosa. Aún los mejores sensores producen ruido y errores sistemáticos en sus lecturas. Por ejemplo, los sensores de radar e infrarrojos pueden dar lecturas diferentes en distancias debido a las propiedades reflejantes de los objetos sobre los cuales inciden sus energías.

Una desventaja es que normalmente los algoritmos que se utilizan en la arquitectura tradicional dedican muchos recursos para interpretar los datos inconsistentes de un sensor o el conflicto que puede suscitarse entre los datos de varios sensores.

El paradigma tradicional es por naturaleza secuencial, lo que significa que primero se toma información, luego se procesa y fmalmente se actúa. Si en este momento se presenta un cambio inesperado en el medio ambiente, el plan puede fallar. Entre mayor sea el tiempo que se dedique a resolver los conflictos de los sensores para refinar el modelo y para optimizar el plan, mayor será el retraso entre el sensado y la acción, lo que aumenta la probabilidad de que se invalide el plan trazado por un cambio repentino.

Otra desventaja de la arquitectura tradicional es que el modelo del mundo incluye todos los detalles geométricos de los objetos con sus posiciones y orientaciones, lo que requiere de una considerable memoria de almacenamiento, además de muchos cálculos numéricos.

Por otro lado los programas realizados en la arquitectura tradicional se basan más en el proceso que en los sensores. Esto limita la capacidad de adaptación del sistema. La síntesis del modelo puede reducir la tarea de interpretación de los datos de los sensores pero desafortunadamente también limita la habilidad del robot para responder autónomamente a los cambios en el medio ambiente.

2.3 Arquitectura reactiva La aparición en 1984 del libro ‘‘Vehieles” de Valentino Braitenberg dio inicio a una nueva etapa para la robótica móvil [JIMJ?NEZ1998]. El autor presenta una serie de vebículos autónomos que ofrecen comportamientos simples como la fototaxis (atracción por una fuente luminosa), o el comportamiento inverso de aversión. Se utilizan términos psicológicos para referirse a los “sentimientos” que se observan en estas máquinas, como miedo o agresión, como si se trataran de animales con un comportamiento complejo a pesar que están construidas sobre conceptos relativamente sencillos.

15

Por otro frente, la arquitectura “subsurntion” presentada en 1986 por Brooks del Instituto de Masachussets dio como resultado una serie de robots-criatiCras que se comportan de manera autónoma dentro de entornos dinámico y que exhiben un nivel de inteügencia próximo al de los insectos [JIMÉNEZ1998]. Esta arquitectura proporciona una forma de combinar un control distribuido en tiempo real a partir de conductas que son disparadas por los datos de los sensores sin que exista un juicio de la validez de éstos.

La ar@ectura reactiva generalmente está integrada por tres niveles independientes rJIMENEZ19981: una capa simbólica, un módulo con capas de conductas y un módulo con servocontroles. En las capas de conductas (figura 2.2), donde las actividades se encuentran distribuidas, el concepto de una representación central se pierde. Cada capa se conecta a los sensores y a los actuadores directamente, es sólo el observador de la criatura el que le atribuye una representación o control central.

Monitorear cambios

Construir mapas

Evitar obstáculos --*

a

S u L

Figura 2.2. Arquitectura reacíiva

Cada capa de la arquitectura se compone de una red de máquinas de estado finito que operan asíncronamente. Las capas se combinan mediante mecanismos de inhibición y supresión que se colocan a la salida y entrada de cada máquina de estados, los cuales controlan de manera selectiva la comunicación entre las capas. El problema de confüctos entre los datos de los sensores se maneja a nivel de las capas de conductas (fusión de conductas) más que en los sensores mismos. Se utiliza un esquema de arbifraje p r i u r i d o para resolver qué conducta toma el control en un momento determinado. No existe la noción de una conducta que llame a otra como una subrutina. En lugar de ello, todas las conductas corren en paralelo pudiendo suprimir las conductas de alto nivel a las de bajo nivel. Cuando las conductas de alto nivel se desactivan entonces las conductas de bajo nivel toman el control de la situación. En este sentido, la arquitectura es inherentemente paralela y los sensores interrelacionan con todas las capas de conducta. No existe una estructura de datos secuencia1 o un modelo geométrico del mundo.

16

Como ejemplo de la arquitectura reactiva considere un robot que siga las orillas de objetos (figura 2.3). La conducta de bajo nivel que podría tener este robot sería un módulo para explorar, el cual haría que el robot se moviera constantemente hacia delante y alrededor de su medio ambiente. Desafortunadamente, en algún momento el robot podría quedar atrapado, para prevenir esta situación se añade otra conducta de evitar que suprima la salida de explorar en el momento que se detecte algún obstáculo. Con estas dos conductas el robot. sería capaz de deambular alrededor de su ambiente por largos periodos, sin embargo, rebotaría continuamente como bola de billar. Para que el robot se amolde mejor al ambiente se puede agregar una tercera conducta de buscar. Este módulo de buscar se encargaría de encaminarse hacia los objetos. Entre buscar y evitar debe existir un balance que mantenga al robot cerca de los objetos pero sin chocar con ellos.

obstáculo buscar

obstáculo evitar

explorar moverse

Figura 2.3: Módulos de conductas (s: nodos de supresión)

2.4 Arquitectura neuro-etológica

En esta arquitectura se estudia el comportamiento animal dentro del hábitat natural considerando su evolución y los mecanismos neuronales que dan origen a ese comportamiento con el fin de incorporarlos en una posible simulación y posteriormente en robots reales. Se pretende incorporar características cognoscitivas de alto nivel en los robots. Se han creado modelos artificiales llamados “animats” (animales-autómatas) que son simulaciones de robots móviles que modelan el comportamiento de animales reales pero sin que se conozcan enteramente los mecanismos neuronales que generan el comportamiento. La arquitectura de control les confiere un comportamiento para resolver problemas de supervivencia, incorporando propiedades básicas como la adaptación y el aprendizaje, lo que les permite desenvolverse en ambientes hostiles y desconocidos.

Como se muestra en la figura 2.4, en el campo de la neuro-etología se pone atención al ciclo de sensución - acción (aspecto que se podría considerar como reactivo o reflejo) y a la representación interna por categorías del medio ambiente (aspecto cognoscitivo).

17

I Robot autónomo

interno

I

A I Entradas (sensación)

Salidas (acción)

I Medio ambiente I Figura 2.4. Ciclo sensación - acción

La arquitectura neuro-etok5gica propone dos módulos [JIMÉNEZ1998], uno que se encargue de elaborar las asociaciones entre determinados estímulos sensoriales y sus correspondientes acciones (coordinación senso-motora), así como la representación interna de estas asociaciones y otro módulo que se dedique a ejecutar las acciones motoras correspondientes, tal como se esquematiza en la figura 2.5.

Entradas

sensomotor y representad activación a

Salidas

Figura 2.5. Arquitectura neuro-etoldgica

Los módulos podrían estar basados en redes neuronales artificiales con un esquema de aprendizaje sencillo que identifique los elementos de un conjunto de estímulos. Estos elementos servirían para entrenar y probar una red neuronal supervisada que haría las veces de la representación interna. Las neuronas de salida del módulo de representación interna darían una respuesta a la situación sensorial actual, esta saüda activaría las neuronas del módulo motor. Lo que se pretende es que estímulos parecidos causen acciones similares buscando obtener capacidades de generalización. El módulo motor podría estar constituido por una red neuronal del

18

tipo generador central de patrones3 y su repertorio de actividad o patrones tendría un componente “heredado O pre-programado” y otro “aprendido” con base en la experiencia y características de la asociación entre los módulos.

Jiménez y Espinosa concluyen que existe una transición o tendencia hacia arquitecturas inspiradas en la biología, dejando atrás a las arquitecturas clásicas basadas en la parte simbólica de la inteligencia artificial clásica. Entre las nuevas arquitecturas existen las que tratan de simular de manera externa el comportamiento animal sin copiar su estructura y funcionamiento interno (reactivas) en las cuales no hay un componente cognoscitivo y otras que tratan de seguir fielmente la forma en que lo hacen los seres vivos (neuro-etológicas). Cabe comentarse que existen otras tendencias no comentadas en este trabajo como las arquitecturas híbndas y otras basadas en el modelo probabilistico.

2.5 Arquitectura basada en agentes

Christoper Geib et al. /GEiB1994] presenta una arquitectura para agentes que busquen y manipulen objetos, la cual implementó en el sistema SodaJack, intentando desarrollar animaciones de figuras humanas realizando tareas especificadas por metas de alto nivel.

Lista de U

Juicio de fadibiüdad (Ma de discrepanck)

Tarea - 1 . c

(mnador)

Directivas de movimiento

Figura 2.6. Diagrama del sistema Sodalack

Son redes neuronales biológicas motoras, aunque reciben un control del cerebro, trabajan de manera automática una vez aprendida la tarea. AI surgir una irregularidad interviene el cerebro para ajustar.

19

G i b parte suponiendo que cuenta con un robot personal como asistenta Muchos de los comandos empleados en el robot requerirán encontrar un objeto X y hacer una actividad Y con él. Por ejemplo, dentro del dominio de una fuente de sodas, el comando “Toma una cuchara y sirve helado” implícitamente significa buscar una cuchara y usarla para servir helado. Esto sugiere que si vamos a diseñar robots como agentes que nos asistan, deben ser capaces de localizar y manipular objetos. El trabajo de Geib enfrenta los problemas de localizar objetos y realizar el razonamiento de bajo nivel requerido para manipularlos.

La arquitectura de SodaJack (figura 2.6) contempla un conjunto de tres planeadores interactivos. Un planeador jerárquico (ItPlanS) usa dos planeadores de propósito especial como expertos, un planeador de búsquedas y un razonador específKo al objeto (OSR) para su manipulación.

El módulo ItPlanS usa un método de expansión de metas para su planeación jerárquica. Este selecciona una expansión para una meta no satisfecha desde una librería de expansiones posibles, usando el ‘estado del mundo’ como puía. Se repite este proceso hasta llegar a un nivel de acciones primitivas. Entonces ItPlanS llama una serie de expertos para verificar que el plan alcanzará la meta Quicio de factibilidad). ItPlans elige entre los planes (generales) conocidos de manera sensible ai contexto, dejando que el planeador de búsquedas y el razonador (expertos) generen nuevos planes para metas conocidas en situaciones específicas.

A continuación se ilustra el funcionamiento de SodaJack con un ejemplo. Considere la meta “Get a scoop” (“toma una cuchara”), ésta puede especificarse como get@) agregando la restricción de que type@) = scoop. ItPlans expande esta meta en submetas: goto(x) y pickup(x) como en la figura 2.7.

type(x) = scoop

goto(x) pickup(x)

Figura 2.7. Descomposición de get@).

ItPlanS considera la acción goto(x) como primitiva pero no especificada a causa de que la variable ‘x’ no está asociada a un objeto particular. Para asociar la variable, el planeador de búsquedas debe ser llamado para generar un plan que permita localizar una cuchara. Con este fin, ItPlanS agrega un nodo finfind y Uama al planeador de búsqueda para generar un plan de búsqueda (figura 2.8).

. . . : . . . . . .

! . . . : . . .

20

El planeador de búsquedas razona desde su conocimiento de la meta de adquisición, en este caso localizar una cuchara, hacia la meta de explorar lugares donde pueda estar alguna cuchara. Satisfacer esta meta requiere buscar físicamente en los lugares posibles.

type(x) = scoop A pickup(x)

c find(x)

Figura 2.8. Adición del nodofind(x).

Si el objeto no es encontrado, el planeador de búsquedas selecciona un sitio para explorar, genera una meta para explorar tal lugar, y lo agrega al plan (figura 2.9).

goto(x) pickup(x)

1 c find(x)

explore(closet23)

Figura 2.9. Estableciendo el primer sitio.

La meta de exploración es expandida posteriormente por ItPlanS (figura 2.10).

Dado que todos los argumentos en la acción están asociados a objetos especEcos, el razonador (OSR) ahora puede ser consultado para verificar que la acción pueda realizarse. Si no es factible, toca a ItPlanS encontrar otra forma de explorar el sitio.

"""I CcNlDÉT ( & k R O DE INFORMACION

21

find(x)

1 explore(closet23)

goto(closet23) open(closet23)

Figura 2.10. Buscando en el primer sitio.

Supongamos que en el ejemplo la acción es factible, ItPlanS se compromete a sn realización e invoca al razonador para que genere una serie apropiada de directivas de movimiento situadas en contexto. Después de explorar el sitio, ItPlanS considera la necesidad de expandir el nodo find otra vez. Usando el planeador de búsquedas para evaluar el progreso de la búsqueda, se examina el entorno para objetos que tengan la propiedad de ser una cuchara. Si una es localizada, la búsqueda termina con éxito. Si no, se selcciona un nuevo sitio para explorar y el proceso de búsqueda se repite hasta no haber más lugares por explorar. Si esto ocurre, la búsqueda termina con fracaso y SodaJack debe rendirse.

Supongamos que la búsqueda termina con éxito, encontrando una cuchara en el closet. El sistema aún no alcanza la meta de conseguir una cuchara. Sin embargo, la variable ‘x’ ya está asociada a una cuchara específica, ItPlanS está en posición de Uamar al razonador para considerar la acción de ir por la cuchara y recogerla (figura 2.11).

get(scoop6)

goto(scoop6) pickup(scoop6)

Figura 2.11. Pian después de la búsqueda.

I ? .

22

Geib concluye en que cualquier sistema que requiera realizar las tareas de búsqueda y manipulación de objetos deberá enfrentar tres principales problemas:

1) planear acciones 2) desarrollar metas para la adquisición del conocimiento 3) adaptar acciones generales de bajo nivel a objetos específicos

Considera que dividir las tareas en componentes separados permite resolver estos problemas de una manera eficiente, y que la integración de tales módulos permite al sistema resolver problemas que cualquiera sistema trabajando solo sería incapaz de lograrlo.

Se observa que el sistema SodaJack se enfocó a un dominio (fuente de sodas) donde no se manejan restricciones en el tiempo de respuesta. La arquitectura propone definir un plan, verificar su validez y ejecutarlo, pero sin tomar en cuenta los posibles cambios dinámicos en el entorno de trabajo. Además se considera que la información necesaria se encuentra en una base de conocimiento usada por el sistema. Por otro lado, el sistema es programado mediante metas de alto nivel, lo que representa una característica valiosa por el proceso jerárquico de expansión de las metas.

2.6 Arquitectura modular

Gregory D. Hager describe en su artículo [HAGER1997] un sistema modular para posicionamiento usando realimentación visual, donde propone una estructura modular para el control de la posición basada en visión, su enfoque consiste en operaciones de control denominadas habilidades primitivas. Cada habilidad primitiva usa realimentación visual para cumplir un requerimiento cinemático del espacio - tarea entre el efector (actuador) del robot y un conjunto de características de un objetivo.

En su trabajo Hager restringe su atención en el posicionamiento basado en visión relativo a un objetivo estático (sin movimiento). Las ideas claves de su enfoque son:

1) Definir algoritmos que calculen la realimentación desde medidas a nivel de imagen obtenidas mediante la observación de características simples tanto en el efector fiuial del robot como en el objeto (objetivo).

2) Una descripción explícita de la relación entre los requisitos a nivel de imagen, las características observadas y las restricciones cinemáticas del espacio - tarea que de ellos se inducen.

3) El uso de visión estéreo (dos cámaras), lo que facilita la definición de requisitos a nivel de imagen con información de profundidad.

23

Las habilidades primitivas se combinan para realizar tareas específicas. La meta del paradigma basado en habilidades es demostrar que desarrollando un pequeño repertorio de habilidades primitivas y un conjunto razonable de operaciones de composición, puede resolverse una gran variedad de tareas en forma robusta, modular e intuitiva, buscando mantener la sencillez tanto en el procesamiento visual como en las interfaces de control.

La información necesaria para generar las habilidades primitivas es extremadamente local: la localización de características tales como esquinas y contornos en una o más imágenes. El procesamiento de imágenes necesario para extraer tales características es sencillo, y puede efectuarse en estaciones de trabajo o en una PC estándar. Hager supone que la interfaz del hardware del robot es un flujo de un sólo tipo de comandos de velocidad o de posición expresados en la base de coordenadas del robot.

Según Hager, “la meta en cualquier problema de control visual es controlar la pose final de un efector relativa a un objeto (objetivo) o características del objetivo”. Aquí el posicionamiento relativo es definido en términos de ‘características observables’ rígidamente asociadas al efector y al objetivo. Sean Ce y Ct el espacio de configuraciones de características observables (en una imagen) asociadas al efector y al objetivo, respectivamente. Sean Te y Tt el espacio de configuraciones de la pose del efector y el objetivo respectivamente, se define a Ci: Ti + Ci, i = e, t como el correspondiente mapeo que relaciona la pose con la confguración de ‘características observables’.

Con estas definiciones, el posicionamiento relativo basado en las caracteniticas de la configuración espacial del robot puede especificarse en términos de un requerimiento sobre la relación entre las características observables.

Se presentan las dos siguientes definiciones en el trabajo de Hager:

1) Una tarea de posicionamiento relativo basado en ‘características observables’ es descrita por una función E: Ce x Ct + %(n). Referida como la ‘función del error’ en el espacio de la tarea. El efector está en la configuración deseada si el error en el espacio de la tarea es cero.

El problema de control visual, según Hager, es definir un sistema de control que mueva el efector a una configuración en la cual el error del espacio de la tarea en la imagen es cero. El efector es modelado como un dispositivo de posicionamiento cartesiano de dos puntos (n=2).

En el trabajo de Hager, todas las características son observadas por un sistema estéreo (dos cámaras), y se calcula un conjunto de medidas llamadas ‘vector de caracterikticas observables’. Sea Fe y Ft un conjunto de todos los valores del vector de características para el efector y el objetivo, se definen los mapeos Fi: Ci 4 Fi, i = e , t para relacionar la pose del efector y el objetivo a su respectivo

24

‘vector de características observables’ en una imagen. (por transitividad, sí Ti -+ Ci y Ci + Fi, Ti -+ Fi, i = e, t hay un mapeo de la pose a las características espaciales y de éstas al vector de características observables).

La realimentación del control está basada en definir una función de error e sobre la configuración de ‘características observables’, tal que e describa la misma configuración cinemática como un error del espacio de la tarea E.

2) Una función de error en la imagen e: Fe x Ft -+ %(n) es equivalente a una función del error en el espacio de la tarea E de grado d < n sí y sólo si

y excepto para posiblemente un pequeño conjunto de configuraciones singulares.

Las ‘configuraciones singulares’ son poses del efector donde el requerimiento sobre la posición definido por la función de error de la imagen e es localmente de grado n más bajo que el grado d de la función equivalente del error de cinemática E (se deduce que d 5 n, por ejemplo, donde no sólo deben coincidir dos puntos sino que tambien deben estar alineados ).

E(ce, ct) = O @ e( Fe(ce), Ft(cf) ) = O para toda ce E Fe y ct E Ft

Hager desarrolló una pequeña biblioteca de requerimientos para la cinemática del espacio - tarea, los cuales tienenfunciones de error en las imúgenes4. Los algoritmos de realimentación para lograr estos requerimientos son las habilidades primitivas. Para una aplicación particular, produce mediante la composición de habilidades primitivas de la biblioteca, un requerimiento para la cinemática espacio - tarea deseada.

1) Posicionamiento punto a punto: formalmente el problema es, dado un punto fijo de referencia P con respecto al objeto (objetivo) y un punto S asociado al efector, desarrollar un regulador que posición del efector tal que P = S. La función del error del espacio de la tarea correspondiente es E(S,P) = S - P . La solución a este problema está basadá en la observación de que los dos puntos sobre la línea base de la cámara son coincidentes en el espacio sí y sólo si sus proyecciones estéreo son coincidentes (coinciden en los planos de las dos cámaras).

2) Posicionamiento punto a línea: dados dos puntos fijos de referencia P y Q con respecto a un objeto (objetivo) y un punto de referencia S asociado al efector, desarrollar un regulador que posicione al efector tal que P, Q, y S sean colineales. La correspondiente función del error del espacio de la tarea está dada por E, (P,Q,S) = (S - P) x (Q - P ) donde E,,, es un mapeo a %(3). Los puntos P y Q definen una línea en el espacio. Sea L quien parametriza esta ünea. Entonces una especificación de la tarea funcionalmente equivalente es: dada una línea de

‘ Hager se refiere a una función de error en la imagen para describir, por medio de características detectadas en una imagen, el error en la configuración de posicionamiento deseada entre el objetivo y el efector.

25

referencia asociada a un objeto (objetivo) y un punto de referencia S asociado al efector, desarrollar un regulador que posicione al eüector tal que S E L.

3) Posicionamiento línea a punto: dada una línea de referencia L asociada al efector y un punto de referencia S asociado al objeto (objetivo), desarrollar un regulador que posicione al efector tal que S E L.

La medida del error para las operaciones punto a punto y punto a línea pueden usarse en conjunto para definir requisitos de cinemática de alto grado (se deduce donde d > n, es decir donde no sólo deben coincidir dos puntos sino que tambien deben eshr alineados).

a) Alinear un desarmado? con un tomillo.

c) Apüar bloques.

........ I' ............ ......... ........ et 'cy ....... ...... j L ......

b) Colocar un disco en la ranura de un lector de discosflexibles.

Figura 2.12. Ejemplos de tareas usando posicionamiento visual

26

Las líneas punteadas y los puntos en la figura 2.12, indican características extraídas para la realización de tareas. A continuación se describen algunos ejemplos de composición de primitivas:

a) Alineamiento: para alinear un desarmador con un tornilio (figura 2.12a), usando sólo las primitivas descritas, se observa que la intersección del tomillo con la superficie define un segundo punto fijo en el tornillo, motivando el siguiente problema de posicionamiento: dada una línea de referencia L asociada al efector y dos puntos S y T asociados al objetivo, desarrollar un regulador que posicione al efector tal que SEL y TEL. Esta tarea puede resolverse usando dos operaciones línea a punto.

b) Alineamiento posicionado: la tarea de insertar (alinear) un disco flexible en la ranura de un lector de discos (figura 2.12b), puede enunciarse en forma de un requerimiento cinemático del espacio de la tarea como “colocar una esquina del disco en el borde de la ranura, y simultáneamente alinear el frente del disco con la ranura”, motivando el siguiente problema de posicionamiento: dado un punto de referencia P sobre una línea L asociada a un objetivo y dos puntos de referencia S y T asociados al efector, desarrollar un regulador que posicione al efector tal que P = S y T E L usando sus proyecciones estéreo.

c) Posicionamiento en seis grados de libertad: suponga que la aplicación requiere una operación de apilado (figura 2.1242),-el requisito cinemático es alinear un lado inferior del bloque superior con el correspondiente lado superior del bloque inferior. Se considera la siguiente definición entre efector y estructuras objetivo: dados tres puntos de referencia no colineales P, S y T asociados al objetivo, y dos líneas de referencia no.paralelas L y M asociadas al efector, desarrollar un regulador que posicione al efector tal que P E L, S E L, y T E M.

El artículo de Hager concluye que la estructura de su sistema de control visual es simple, robusto, modular y portable, donde una amplia variedad de habilidades de posicionamiento pueden ser desarrolladas, así como una rica noción para la composición de habilidades. En particular, todas las habilidades descritas aquí se han enfocado en mover puntos y líneas dentro de un “contacto visual” con algún otro punto o línea.

Para los fines del actual proyecto de tesis, el enfoque de Hager se considera muy interesante, por su modularidad, sencillez y por la amplia variedad de tareas que pueden ser tratadas sin necesidad de equipo sofisticado para el procesamiento de imágenes.

27

2.7 Arquitectura cliente - servidor

OIaf Kubitz et al. presenta en su artículo [KUBITZ1998] un control para robot móvil basado en el modelo cliente - servidor, donde señala que su enfoque brinda características como el reuso, la portabilidad y facilidad para el mantenimiento mediante la abstracción de los datos.

De acuerdo con Kubitz, un enfoque cliente - servidor permite al diseñador modelar los recurnos (sensores) como servidores accedidos por clientes (procesos de control). El enfoque cliente - servidor ha demostrado ser un paradigma exitoso en la ingeniería de software, que proporciona a los desarrolladores y usuarios ventajas tales como la portabilidad, reusabilidad, abstracción de los datos por capas, así como facilidad para la prueba y el mantenimiento de los sistemas.

Debido a que cada recurso (sensor o actuador) difiere en su funcionalidad, se implementa en un servidor separado como muestra la figura 2.13, lo que conduce tener un número de servidores, cada uno proporcionando acceso a otro sistema sensor o actuador.

Estructnra de manejo de

eventos

actuador actuador actuador

E n t o r n o

Figura 2.13. Partes orientadas a recursos y aplicacwnes de una estructura

Las capa de los clientes contienen los procesos de la aplicación, provistos de un conjunto de funciones para acceder a los recursos a través de la capa de servidores. La comunicación entre procesos (IPC) entre la capa cliente y la capa servidora está basada en una estrnctura de manejo de eventos, permitiendo capacidad de respuesta en tiempo real.

28

Los clientes pueden ser consumidores o proveedores. Pueden recibir datos de los servidores (sensores o datos internos) o pueden enviar datos a los servidores (actuadores). En el Último caso, el servidor envía los datos al receptor apropiado @or ejemplo un efector). En el primer caso, el servidor distribuye los datos del sensor a todos los procesos clientes que requieran ese dato específico.

La capa de servicio implementa la liga lógica a los sensores y actuadores. Proporciona acceso a los datos del sensor o comandos del efector de forma abstracta de la conexión física detrás del recurso. La capa de servicio oculta los mecanismos de acceso detrás de los sensores y actuadores en capas más bajas, por ejemplo los protocolos de comunicación y las direcciones de puertos del hardware. Los clientes pueden acceder a los recursos iniciando una solicitud a un servidor. La estructura del acceso al recurso es independiente de los datos y del tipo de recurso. En el trabajo de Kubitz se presentan varios métodos de acceso, llamados clases.

Cada servidor puede ser dividido en tres partes (véase figura 2.14), la interfaz del programa, la sección de trabajo y la interfaz del hardware.

I Sensor I I Actuador

Figura 2.14. Detalles del servidor

29

Los procesos de aplicación (clientes) tienen acceso a la capa de servicio por medio de la interfaz del programa de aplicación del servidor (API) en la parte de Utterfaz del programa. Esta sirve para despertar y notificar a los procesos clientes que requieran datos de los sensores relacionados.

La interfaz de hardware proporciona acceso a las interfaces seriales o paralelas, trata con los protocolos de comunicación de los subsistemas de los sensores y efectores, y es responsable de la notificación inmediata al API del servidor sobre nuevos datos disponibles.

La sección de trabajo interconecia a las interfaces de programa y de hardware, manejando el flujo de datos desde y hacia la API del servidor y, por otro lado, sirve como una separación entre las partes orientadas al hardware y las partes orientadas a la aplicación del servidor. Los procesos de entrada y los procesos de salidu de la parte de interfaz del hardware están orientados hacia una eficiente comunicación con los recursos, es decir, los procesos se vuelven activos cuando nuevos datos están disponibles para el hardware o desde el hardware y duermen en el entretiempo. Por otro lado, la API del servidor tiene que esperar a una solicitud de algún cliente.

La memoria compartidu se usa para la comunicación dentro de la sección de trabajo, necesita estar protegida por semáforos para evitar conflictos durante accesos de

de IPC. Esto ofrece la posibilidad de simular ciertos sensores y efectores, permitiendo conmutar entre datos simulados y reales, lo que permite probar las aplicaciones.

Dentro de la sección de trabajo se usan eventos (servicio de mensajes asíncronos) para notificar al cliente sobre nuevos datos en la memoria compartida. La ventaja es que no hay riesgo de bloqueo entre las partes de interfaz de programa e interfaz de hardware, una espera a la otrá. Así, las interfaces están desacopladas por este mecanismo de eventos. Por lo tanto, esto favorece la reacción en tiempo real del sistema, debido a que la atención del servidor se enfoca a los nuevos eventos.

De acuerdo con Kubitz, este enfoque por capas proporciona abstracción de los mecanismos de comunicación del hardware, de tal forma que los accesos a los sensores y actuadores pueden ser fácilmente intercambiados (capas internas o de servidores) sin la necesidad de reprogramar módulos (capas externas o de clientes).

escritura. La memoria compartida es muy eficiente y proporciona un medio rápido I!

30

Comunicación cliente servidor

Para ofrecer mecanismos de comunicación de acuerdo a los procesos de control que demandan tiempo real, se introducen clases de acceso a los recursos, con propiedades de acuerdo al tipo de dato transmitido, es decir, propiedades que no son directamente relacionadas el modelo cliente servidor. En vez de proporcionar a los clientes flujos o corrientes de datos continuas, los datos son enviados de acuerdo a las clases elegidas. El cliente puede asociarse a un servidor usando una cierta clase de comunicación y recibirá los datos de acuerdo a las propiedades de la clase solicitada. Una clase es un conjunto de propiedades con sus atributos. Existen varias propiedades de clases que pueden ofrecer los servidores a los clientes (véase tabla 2.1).

De acuerdo a sus necesidades, los clientes seleccionan entre las propiedades disponibles de un servidor aquéllas que son adecuadas para su tarea. La ventaja del enfoque cliente - servidor orientado a clases está en poder extender el sistema si el robot fuera equipado con nuevos sensores que requieran mecanismos de comunicación adicionales o que tengan dependencias diferentes de las clases conocidas. Estos sensores pueden ser fácilmente integrados al sistema. Las dependencias y los módulos de comporiamiento que no usan el nuevo sensor permanecen sin ser afectados por las nuevas clases.

Tabla 2.I.Propiedades de la clase de comunicación de datos entre clientes y servidores.

A continuación se describen tres modelos usando clases de comunicación:

1) Modelo 1 - Interactive Pull: es el método usual del acceso de un cliente a un servidor, las propiedades de clase y sus atributos son :

Class-Interactive-Pull = { categoría : = más reciente, método acceso : = interactivo. Comunicación := shcrona

1

31

Figura 2.15. Vis.% compacía del modelo de comunkaci6n I - interactive pull

La figura 2.15 ilustra la comunicación del primer modelo en forma intuitiva.

La API del servidor está bloqueada por receive(), esperando la solicitud de un cliente. El cliente hace una solicitud al servidor usando la primitiva send(). El servidor entonces consigue el dato más reciente y lo envía al cliente usando la . primitiva reply(). “Más reciente” significa que el dato ya está disponible en la memoria compartida de la sección de trabajo del servidor al tiempo de la solicitud. El servidor no tiene que esperar a que arriben nuevos datos. El cliente está bloqueado mientras espera la contestación, tan pronto como el servidor esté listo, el cliente recibe el dato disponible más reciente.

Este modelo es principalmente usado por clientes que necesitan datos del sensor instantáneamente, sólo esporádicamente, o con una frecuencia fija.

2) Modelo 2 -Interactive, Blocked Pull: usado para recibir los datos más nuevos tan pronto como estén disponibles. Este segundo modelo tiene las siguientes propiedades y atributos de clase:

Class-Interactive-Blocked-Pull = { categoria := más nuevo, método acceso := bloqueo interactivo, comunicación := síncrona

)

La figura 2.16 muestra la forma en que la clase trabaja. Consideremos un servidor que inicia con un send() a un cliente. Entonces el servidor puede quedar bloqueado (en caso de que el cliente no esté listo). Esto no es deseable, debido a que el servidor

32

puede estar disponible para otros clientes también. Por lo tanto, se usa un mecanismo de manejo de eventos.

Los clientes hacen una solicitud al servidor usando send(), el cliente entonces queda bloqueado. Una solicitud para el ‘interactive, blocked pull” comunica al servidor que almacene la solicitud (es decir al ideutificador del proceso del cliente) y conteste la solicitud después de que nuevos datos estén disponibles. Durante este tiempo, el cliente está bloqueado y espera una contestación del servidor.

El arribo de nuevos datos a la interfaz de hardware del servidor causa la notificación de la API del servidor a través de la sección de traba,jo, esto se hace con un evento de comunicación asíncrono (véase figura 1.14). La API del servidor al ser notificada sobre los nuevos datos disponibles, contesta con reply() a todos los clientes que esperan por los datos.

Debido a que está bloqueado por send(), el cliente no consume tiempo de cómputo mientras espera por nuevos datos. Sin embargo, en ese tiempo, el cliente no perderá ningún dato del sensor.

Este modelo es principalmente usado por clientes que realizan una tarea pequeña cuando arriban nuevos datos y que se duermen en el entretiempo. Por ejemplo un módulo que solicita datos y los distribuye después de filtrarlos.

evento i z i

Figura 2.16. Vista compacta del modelo de comunicación 2 -interactive, blockedpulL

33

3) Modelo 3 -Automatic Push: el segundo modelo tiene como inconveniente que el cliente queda bloqueado cuando espera por nuevos datos de un servidor específico. Por lo tanto, el cliente no es capaz de esperar datos más que de un senidor. Esta es una seria limitación para la mayoría de las aplicaciones, debido a que evita el uso concurrente de más de un recurso, por lo que se introduce el tercer modelo de comunicación denominado “Automatie push” el cual notifica al cliente cuando nuevos datos estén disponibles, y ofrece la oportunidad de que el cliente no esté bloqueado el tiempo que espere por nuevos datos. Este es un servicio automático, es decir, cuando se suscribe, el cliente es informado cada vez que nuevos datos estén disponibles.

El cliente tiene que preguntar por los datos (pull) después de la notificación de nuevos datos en el servidor (push). Esto debido a que el mecanismo de notificación asíncrono no puede transmitir variables de datos al consumidor. El tercer modelo tiene las siguientes propiedades y atributos de clase:

ClassAutomatic-Push = (

método de acceso := continuo automático, comunicación := asíncrona

categoría := el más nuevo,

1

En particular este modelo proporciona eficiente acceso a múltiples recursos en tiempo real por un cliente, por ejemplo un sistema de comportamiento. El tercer modelo de comunicación puede considerarse una extensión del segundo modelo (figura 2.17)

send()

/’

\ / - = i.

Figura 2.1 7. Vista compacta del modelo de comunicación 3 - automatic push.

34

El cliente se suscribe al senidor, para ello utiliza send() y recibe una respuesta inmediata sobre la aceptación del modelo de comunicación. Entonces el servidor avisa a todos los clientes suscritos cada vez que nuevos datos estén disponibles. Los clientes obtienen entonces tales datos del servidor, usando otra vez el primer modelo de comunicación.

La ventaja de este tercer modelo es que el cliente puede suscribirse a más de un servidor (recurso) y recibir los datos del servidor que entregue los datos primero. Además, el cliente no pierde'ninguna notificación sobre nuevos datos de ningún servidor al que esté suscrito. Un cliente que esté recibiendo nuevos datos de un servidor conseguirá la notificación de un segundo servidor tan pronto como el cliente haya finalizado la comunicación con el primer servidor.

Las características alcanzadas por la estructura cliente - servidor de manejo de eventos pueden resumirse en los siguientes puntos:

1. La potencia de cómputo es consumida sólo para procesar datos necesarios. 2. No hay necesidad de estimar el tiempo de arribo de los datos para obtenerlos

de forma oportuna. 3. La comunicación en tiempo real tiene una alta eficiencia y una carga muy

baja, especialmente para notificación de múltiples destinos. 4. La estructura de manejo de eventos permite a las aplicaciones de control

reaccionar dependiendo de la situación actual y enfocar su atención adecuadamente.

5. Los clientes reciben exactamente los datos requeridos para realizar su tarea 6. La programación del manejo de eventos y la integración de procesos por la

arquitectura de control proporciona una fuerte unión de los sensores y los mecanismos de control, así mismo proporciona un diseño de módulos de control con capacidad de tiempo real.

Kubitz concluye su artículo señalando que el concepto expuesto ha sido implementado con éxito para todos los sistemas sensores y efectores sobre su robot móvil de prueba, afirmando que resulta ser flexible y ha sido adaptado a una amplia variedad de protocolos de comunicación. Por lo tanto, el cliente gana acceso a los datos independientemente del hardware o de las estructuras de comunicacióu del sensor.

35

2.8 Conclusiones En este capítulo se hizó un estudio de las arquitecturas encontradas para integrar ia información obtenida por dispositivos sensores, con los procesos para controlar de manera dinámica a los robots.

En resumen las arquitecturas analizadas fueron la deliberativa o tradicional, la reactiva, neuro-etológica (basada en redes neuronales artificiales), la basada en agentes, la modular y la cliente - servidor. Puede hacerse una división mas general, clasificando las arquitecturas en tres grupos: las deliberativas (como la tradicional y la basada en agentes), las reactivas (como la neuro-etológica y la reactiva), y las hiaridas (como la modular y la cliente - servidor).

Para los fines del actual proyecto de tesis la arquitectura cliente - servidor propuesta por Kubitz resulta muy atractiva, por su modularidad, por estar orientada hacia los eventos que ocurren en el entorno, y por buscar establecer un nivel elevado de abstracción para el acceso de los datos de sensores y para el control de los dispositivos. Esto concuerda con el propósito de la tesis, donde se tiene por objetivo definir una arquitectura que facilite el diseño y la integración modular de sistemas de visión con robots para la automatización de tareas.

36

CAPÍTULO 3 ESQUEMA DE INTEGRACIÓN

3 Esquema de Integración

En el estado del arte se mostró que las actuales arquitecturas de control se están integrando con conceptos inspirados en la biología [JlMÉNEZ1998], en agentes rGEIB19941, en primitivas o funciones básicas [HAGER1997] y en el modelo cliente - servidor [KUBITZ1998]. En esta sección se detalla el esquema propuesto y para abordar el tema de las arquitecturas, iniciamos este capítulo presentando la relación entre sistemas y arquitecturas, los principios de una buena arquitectura y los criterios de evaluación [RECHTIN1991]; después se presenta el esquema conceptual de la arquitectura propuesta para la integración de la visión artificial al control de robots, continuando con la definición de los sistemas de visión y el esquema para los servidores de visión, seguido por la definición de los sistemas controladores, así como del esquema para los servidores de control. Posteriormente se define el esquema para los clientes y por último se propone un mecanismo para el manejo de eventos.

3.1 Arquitecturas y sistemas

De acuerdo con Rechtin [RECHTIN1991], una arquitectura es un conjunto de definiciones, reglas y términos que se emplean para construir sistemas, es una manera o esalo de construir caracterizado por ciertas particularidades. Un sistema es un conjunto de elementos que se combinan para obtener un resultado. Se dice con respecto a los sistemas, que él todo es mayor que la suma de las partes, es decir, un sistema organizado tiene propiedades más allá que cualquier colección de componentes sin ninguna integración. El propósito de construir sistemas es ganar tales propiedades. La Única cosa agregada a los componentes de un sistema para hacerlo mejor que la suma de las partes es su integración. Esta relación entre los componentes es lo que da al sistema su valor agregado. La esencia de un sistema esta en sus relaciones, sus interfaces, su estructura, su capacidad y en la función que tiene. Hacer una arquitectura es la búsqueda de una estructura que produzca una solución satisfactoria en una forma razonablemente simple. Se reconocen las limitaciones del método científico en el diseño de arquitecturas, así que los científicos, ingenieros y arquitectos siguen la heurística de simplificar, simplificar y simplificar [RECHTIN1991].

37

3.2 Principios de una buena arquitectura La esencia de una arquitectura es su función y su forma (estructura), su equilibrio entre capacidad y compromiso. El reto de las arquitecturas es reducir la complejidad y controlar la incertidumbre. En la figura 3.1 se muestran algunos de los intereses que compiten en el diseño de una arquitectura [RECHTIN1991].

del sistema

Complejidad entorno

imperativos del

!

Forma

Figura 3.1. Algunas tensiones en la arquitectura de Sistei?IaS.

En la figura 3.1 los intereses de diseño se muestran como fue- que actúan como tensores de la arquitectura. En el diseño de la arquitectura se contraponen los requerimientos del sistema con los imperativos del entorno, las altas necesidades del sistema se tienen que regular de acuerdo al costo de satisfacerlas, la complejidad de los sistemas dificulta la simplicidad en el diseño, y del mismo modo, se confronta la función con la forma de hacerlo. De esta manera, una arquitectura debe cumplir con un balance entre los factores que afectan su capacidad para realizar una función.

A continuación se enumeran los principios de una buena arquitectura de sistemas de información [RECHTIN1991]:

1. Consistencia: la arquitectura tiene fundamentos y proporciona estabilidad. 2. Ortogonalidd los elementos de la arquitectura son relativamente

independientes unos de otros. 3. Apropiada: la arquitectura esta enfocada a funciones bien definidas, no hay

funciones innecesarias. 4. Parsimonia: los elementos de la arquitectura no tienen redundancia funcional. 5. Transparencia: La arquitectura aísla al usuario de la complejidad funcional.

38

6. Generalidad: la arquitectura cumple con múltiples propósitos generales de diseño.

7. Abiertu: la arquitectura esta adaptada para responder a eventos y condiciones cambiantes.

8. Completa: la arquitectura resuelve las necesidades de los sistemas.

Respecto a las tensiones en la arquitectura de sistemas, se dice que un sistema complejo no puede ser óptimo para todas las partes involucradas ni optimizado para todas las funciones.

3.3 Criterios de evaluación

El objetivo de este trabajo de tesis es definir una arquitectura para la integración de la visión artificial al control de robots, donde los elementos de la arquitectura sean módulos reutilizables e interoperables (véase sección 1.1). Para valorar hies aspectos es necesario establecer los criterios de evaluación, los cuales servirán para identificar las propiedades particulares de la arquitectura propuesta.

A continuación se definen los conceptos de abstracción, modularidad y encapsulación [JOYANES1996], para que sirvan como criterios de evaluación de la arquitectura propuesta.

a) Abstracción: la abstracción es un medio para enfrentar la complejidad inherente al software y a los sistemas. La abstracción es una propiedad que permite representar las características esenciales de un objeto o sistema, sin preocuparse de las restantes características no esenciales. Una abstracción se enfoca en la vista externa de un objeto o sistema, de modo que sirva para separar el comportamiento esencial de su implementación. Definir una abstracción significa describir una entidad del mundo real, no importa lo compleja que pueda ser, y a continuación se utiliza esta descripción en un programa.

b) Eucapsulación: el encapsulamiento es la propiedad que p e d t e asegurar que el contenido de la información de un objeto o sistema esta oculto al mundo exterior. La encapsulación es el proceso de ocultar todos los secretos de un objeto o sistema que no contribuyen a sus características esenciales. La encapsulación permite la división de un sistema complejo en módulos.

c) Modularidad: la modularidad es la propiedad que permite subdividir una aplicación o sistema en partes más pequeñas (módulos), cada una de las cuales debe ser tan independiente como sea posible del sistema en sí y de los módulos restantes. Cada módulo debe tener dos partes, una interfaz y una implementación (encapsulada). La interfaz de un módulo captura sólo su vista externa y la implementación contiene la representación de la abstracción, así como los mecanismos que realizan el comportamiento deseado.

39

La reutilización de los módulos ya desarrollados para otras tareas (tanto de visión como de control) puede facilitar y acelerar significativamente el proeeso de desarrollo de prototipos y sistemas de robots controlados mediante visión máquina. Esto resulta deseable en el área de la robótica, donde los componentes de software son bastante específicos al hardware (lo opuesto a la portabilidad), aun en los casos de sensores y actuadores similares [KUBITZ1998].

Para resolver el problema de la portabilidad, dentro de la arquitectura desarrollada se propone que el acceso a los recursos (sensores y efectores) sea por medio de API’s

dispositivos (sistema de visión o manipulador) por otro recurso similar no significa una modificación en las aplicaciones de control. El diseñador de un sistema de esta naturaleza no tiene que preocuparse por lidiar con los dispositivos, solo tiene que conocer las interfaces para tener acceso a los recursos, de manera análoga a como se trabaja con la información de un manejador de base de datos vía una interfaz genérica de ODBC’.

(Interfaz de Programas de Aplicación) de alto nivel. Así, un cambio de alguno de los I1

3.4 Esquema conceptual

La arquitectura para el control de robots mediante visión que se propone en el presente trabajo de tesis busca incorporar las siguientes características:

Reusabilidad, es decir que los algoritmos para el procesamiento de imágenes y para el reconocimiento de formas, así como para el control de tareas que sean desarrollados para un sistema, puedan servir para una variedad de tareas y sistemas distintos. En otras palabras, no tener que reinventar el hilo negro cada vez que se pretenda implementar una tarea distinta.

Portabilidad, en el campo de la robótica, los módulos de software por lo común están orientados hacia el hardware específico, esto es lo opuesto a la portabilidad, por lo que es deseable un enfoque que facilite la integración de distintos componentes de visión y de control.

Abstracción en el manejo de datos, el diseñador de un módulo para realizar el control inteligente de un robot no debería tener que preocuparse por las direcciones de puertos del hardware, ni por los protocolos de comunicación, ni por las secuencias de los comandos y demás detalles, sino en la información necesaria para realizar el control y obtenerla de manera sencilla.

Facilidad para la realización de pruebas y mantenimiento, es importante que sea posible realizar prnebas ya sea con datos simulados o reales, para poder conocer las capacidades de los componentes y realizar mejoras en el desempeño de los algoritmos, así como un crecimiento escalar de los sistemas.

Open Data Base Conneeti~ty.

40

Teniendo en cuenta los punto anteriores, se propone una arquitectura cliente - servidor como la introducida por Kubitz [KUBITZ1998] ya mencionada en la sección 2.7, donde los detalles sobre los procesos de visión queden ocultos y los datos sean accedidos en forma de solicitudes de los clientes hacia los servidores (véase figura 3.2).

El modelo cliente - servidor se adopta porque propone dividir el trabajo de manera natural, permitiendo la especialización de los servidores y el acceso abstracto a la información en los clientes, los cuales logran independencia de los dispositivos físicos, simplificando de esta manera el desarrollo de las aplicaciones, al permitir enfocarse en los algoritmos para desempeñar los procesos, más que en los mecanismos para obtener información.

Manejo de

eventos

J E n t o r n o

Figura 3.2 Arquitectura propuesta basada em el modela cliente - servidor.

Visto de abajo hacia arriba, la arquitectura que se propone está compuesta por uno o más servidores que distribuyen la información que se adquiere desde los sistemas de visión, además de otro servidor que se ocupa de atender las solicitudes de los clientes hacia el controlador del robot. Los clientes llevan la secuencia y la lógica de la tarea que se pretende realizar. Un mecanismo de manejo de eventos permite responder dinámicamente ante los cambios del entorno. Nuevos módulos pueden ser incorporados dentro del esquema, los programas o algoritmos de control serán incorporados como módulos clientes y podrán interactuar con los servidores haciendo uso de las interfaces de visión y de control. Si se desea incorporar un nuevo robot, será necesario definir otro módulo servidor que implemente la interfaz de control para permitir a los módulos clientes la comunicación con el controlador del robot. De igual forma, para incorporar nuevos sistemas de visión será necesario definir otro módulo servidor que implemente la interfaz de visión para'permitir a

41

los módulos clientes obtener la información visual que requieran. De esta f o m , los módulos clientes que sean desarrollados podrán funcionar independientemente de los dispositivos de visión y de control que S e a n utilizados.

1

3.5 Sistemas de visión

Uno o más sistemas de visión pueden integrarse dentro de la arquitectura (véase figura 33). Por ejemplo, un sistema de visión puede estar enfocado en obtener la

otro sistema de visión distinto estar dedicado a obtener la información respecto a las esquinas que se localicen en la misma imagen. Puede ser que los sistemas de visión compartan la misma imagen adquirida o que tengan distintos dispositivos digitalizadores de imágenes. Los sistemas podrían estar trabajando en paralelo en un mismo procesador o de manera distribuida en procesadores distintos.

información respecto a los contornos dentro de una imagen del entorno del robot y I

SISTEMA DE VISION SISTEMA DE VISION EXTRACCION DE EXTRACCION DE

I I u u I I M A G E N I

1 TARJETA DIGITALIZADORA I Figura 3.3 Extracción de caracterlFticas en paralelo.

Existen varios sistemas de visión realizados como trabajos de tesis en el Cenidet [IGLESIAS1991], [GARCIA1997], [PENICHE1998], [VELARDE19981 y [MEDINA1998], los cuales pueden servir como base para el desarrollo de sistemas de visión prototipos para la detección y el reconocimiento de objetos en dos dimensiones. Además existen varias herramientas de software o tooíkits que pueden emplearse para formar un sistema de visión y que se encuentran de forma pública y gratuita en Internet. Como ejemplos de tales herramientas, las cuales no requieren equipo especializado para el procesamiento de imágenes, están los sistemas X-vision IHAGER19951, SUSAN [SMITH19981 y DIAS [JENA].

Una parte importante dentro de un sistema de visión es el modelado interno del mundo o la base de conocimiento, donde se incluyen los detalles geométricos de los objetos con sus posiciones y orientaciones, el conocimiento a priori de los obstáculos y demás restricciones existentes. La ventaja es que permite tomar decisiones con base en información global del entorno. La desventaja es que se requiere de mucha

42

memoria para la representación y muchos cálculos para las decisiones que se realicen a partir de tal información.

3.6 Servidores de visión

Los servidores de Visión serán los que proporcionen la información de las características visuales para el control. De manera análoga a un controlador de ODBC (Open Data Base Connectivity), los servidores facilitarán una interfaz de acceso a los datos de visión que los diseñadores de los módulos de control @recesos clientes) podrán utilizar para realizar tareas de posicionamiento. La interfaz de un servidor de visión servirá como una capa que oculta los mecanismos de los sistemas de visión tales como los algoritmos de segmentación, extracción de características (centro, área, orientación, momentos, etc.) y reconocimiento de formas. Puede ser que algunos de los servidores de visión constituyan habilidades primitivas de posicionamiento basadas en puntos y líneas, como las descritas por Hager [HAGER1997], donde la interfaz de tales servidores permita que los clientes definan puntos y líneas para que los servidores realicen los cálculos de lasfunciones de error de imagen6, y los clientes encargados del control regulen las tareas de posicionamiento (véase figura 3.4).

CLIENTE REGULADOR DE POSICION BASADO EN IMAGEN

Definición de coordenadas de puntos y líneas para

posicionamiento

(HABILiDAü PRIMITIVA) CALCULO DE LA FUNCION DE

ERROR DE IMAGEN

EXTRACCION DE PUNTOS Y LíNEAs

U SEGUIMIENTO DE LA

U POSICiON INICIAL

Figum 3.4 Habüidadgrimitiva de posicionamiento vixta como servidor de viswn

Como se expone en la sección 1.2.1.5 página 13, de acuerdo con Hager, una función de error de imagen es equivalente a una función de error de la posición en el espacio de la tarea.

43

Los senidores de visión estarán compuestos por tres partes: una API (interfaz para programas de aplicación), una sección de trabajo y una interfaz para el sistema de visión (véase figura 3.5).

La API del servidor de visión es el medio por el cual los clientes deben solicitar y recibir la información visual que requieran para realizar alguna tarea de control. La interfaz para el sistema de visión envía los datos de la información visual desde un sistema de visión hacia el senidor de visión. Esta interfaz debe ser capaz de notificar de manera inmediata a la API del senidor de visión cuando hay nueva información disponible.

CLIENTE I PROGRAMA DE CONTROL

r-i Sistema de visión

Figura 3.5 Servidor de visión.

La información visual puede generarse de un proceso simulado de visión que arroje valores predeterminados para una serie de objetos empleados dentro de la tarea de

44

manipulación, esta simulación permitirá probar fácilmente las aplicaciones de control que se desarrollen.

La sección de trabajo debe encargarse del flujo de la información generada por el sistema de visión, permitir que fluya desde la interfaz para el sistema de visión hacia la API del servidor de visión. Esta sección es necesaria, como lo señala Kubitz [KUBITZ1998], para satisfacer dos orientaciones de dependencks contradictorias. Una parte orientada hacia una comunicación eficiente con el recurso (la interfaz para el sistema de visión) y otra orientada a proporcionar un acceso sencillo y oportuno de los datos requeridos por los clientes (la API del servidor de visión).

Para facilitar el flujo de la información, dentro de la sección de trabajo, se hará uso de memoria compartida. La memoria compartida tiene que estar protegida por un mecanismo de semáforos wRQUEZ19931 para evitar conflictos durante la escritura de información. La memoria compartida es muy eficiente y proporciona un medio rápido de comunicación entre procesos (IPC). Además permitirá realizar pruebas con recursos (sistemas de visión) simulados y reales, proporcionando una manera de probar y depurar aplicaciones.

Un mecanismo de eventos (servicio de mensajes asíncrono) será utilizado, dentro de la sección de trabajo, para que el servidor de visión notifique a su cliente o clientes sobre la disponibilidad de información en el buffer de datos (memoria Compartida). La ventaja de tal mecanismo de notificación asíncrona es que evita el riesgo de bloqueos entre la interfaz del sistema de visión y el API del servidor de visión, de tal forma que una espera a la otra. Así las interfaces se encuentran desacopladas mediante el mecanismo de eventos, lo que permitirá dar respuestas oportunas a los clientes, debido a que la atención del servidor se enfoca en los nuevos eventos que reporte el sistema de visión.

'!

45

-b del robot (planta)

Controlador

I _ _ _ _ _ _ _ _ - _ _ _ _ _ _ _ _ _ _ _ _ _ - - - _ _ _ _ _ I

Elementos de realimentación

Posición 'I ("e,oeidad)

Figura 3.6 Diagrama de bloques con In configuración @iea de un sistema de conirol para una articulación de un robot.

El controlador generalmente consiste de sumatorias donde las señales de entrada y salida se comparan (véase figura 3.6), un dispositivo de control el cual determina la acción de control, los amplificadores de potencia necesarios y los dispositivos hardware asociados para realizar la acción de control en la planta. El actuador es usado para convertir la acción de control en los movimientos físicos del manipulador. El control y el actuador pueden ser operados por medios electrónicos, mecánicos, hidráulicos, o neumáticos, o combinaciones de éstos. Hay cuatro acciones de control básicas: control on - off, proporcional, derivativo e integral. Las acciones de control se usan de manera simple o combinada para proporcionar seis tipos comunes de controlador [GROOVER1986]:

1. Controlador on - off, con sólo dos niveles de control, totalmente encendido o apagado. Un ejemplo son los termostatos caseros, que se encienden y se apagan automáticamente.

2. Controlador proporcional, usado cuando se requiere una acción de control más suave, proporciona una señal de control proporcional al error. Cuando el error sea grande la acción de control será mayor y cuando el error sea pequeño la acción de control será de menor intensidad.

3. Controlador integral, la señal de control se cambia a una tasa proporcional a la señal de error, es decir, si la señal de error es grande, la señal de control se incrementa rápidamente; si la señal de error es pequeña, la señal de control se incrementa lentamente. Si el error tiende a cero, la salida del controlador podría permanecer constante. Esta característica permite que se usen en

46

donde hay tiPo de carga constante en el sistema. Aun si no hay error el controlador Puede mantener una señal de salida para contrarrestar la carga.

4. Controlador proporcional más integral (PI), a veces es necesario combinar las acciones de control. Un controlador proporcional es incapaz de contrarrestar una carga en el sistema con error cero. Un controlador integral puede trabajar con error cero pero da una respuesta lenta. AI combinar las acciones se resuelve el dilema de control.

5. Controlador proporcional más derivativo (PD), El control derivativo proporciona una señal de control proporcional a la tasa de cambio de la señal del error. Dado que puede no generar salida a menos que la señal de error cambie, es raro que se use solo. El efecto del controlador es anticipar los cambios en el error y proporcionar una respuesta más rápida a los cambios.

6. Controlador proporcional más integral más derivativo (PID),es el tipo de control más general y más usado. Proporciona una respuesta rápida, buen control de la estabilidad del sistema y baja permanencia en estado de error.

Cabe mencionar que existen otros tipos de controladores como los difusos y los adaptativos no cubiertos en este trabajo. Se hace notar que el controlador C500 del robot CRS modelo T476, utilizado para la integración del prototipo propuesto, emplea un control tipo PID.

3.8 Servidores de control

Los servidores de control deberán proporcionar un conjunto de comandos para controlar los movimientos del robot, para lo cual facilitarán una interfaz que los diseñadores de los módulos de control (procesos clientes) podrán ualizar para indicar los movimientos que requieren del brazo manipulador.

La interfaz de un servidor de control servirá como una capa que oculta los mecanismos de acceso al controlador y los actuadores, como son los protocolos de comunicación y los puertos de hardware. Un servidor de control estará compuesto por tres partes: una API (interfaz para programas de aplicación), una sección de trabajo y una interfaz para el controlador (véase figura 3.7).

La API del servidor de visión es el medio por el cual los clientes deben solicitar y recibir la información de la posición del brazo robot que requieran para realizar alguna tarea de control. En las secciones 5.4 y 5.5 se definen las interfaces para el control. La interfaz para el controlador envía los datos de la posición actual desde el controlador hacia el servidor de control. Esta interfaz debe ser capaz de notifcar de manera inmediata a la API del servidor de control cuando hay nueva información disponible sobre el estado o posición del robot. La interfaz para el control estará orientada hacia una comunicación eficiente con el controlador y la API del servidor

47

de control estará enfocada a proporcionar un acceso sencillo a los datos requeridos por los clientes.

CLlENTE PROGRAMA DE CONTROL

I Controlador

Figura 3.7 Servidor de control.

La sección de trabajo debe encargarse del flujo de la información generada por el controlador, permitir que fluya desde la interfaz para el sistema de control hacia la API del servidor de control. Para agilizar el flujo de la información, dentro de la sección de trabajo, se hará uso de memoria compartida, por ser la forma más rápida de comunicar procesos en sistemas operativos como UNM, Windows y QNX, este Último con características para tiempo real (véase sección 6.6). Para enviar datos de un proceso a otro, sólo hay que escribir en la memoria compartida y automáticamente esos datos están disponibles para que los lea otro proceso que comparta la memoria [MÁRQUEZ1993].

48

Un mecanismo de eventos (lectura conducida por eventos [MÁRQUEZ1993]) será utilizado, dentro de la sección de trabajo, para que el servidor de control notifique a su cliente o clientes sobre la disponibilidad de información en el buffer de datos (memoria compartida).

La respuesta del dispositivo de control puede generarse desde un proceso simulado (usando MatLab o algún simulador gráfico) que responda de acuerdo al modelo matemático del robot, esta simulación permitirá probar las aplicaciones de control que se desarrollen.

3.9 Clientes

Los clientes son los procesos de aplicación, los encargados de llevar la secuencia lógica para la realización de las tareas. Disponen de un conjunto de funciones (API's de los servidores) para obtener información visual y para ordenar movimientos al controlador del robot (véase fig. 3.7) de acuerdo a un algoritmo de control. Los procesos clientes serán programas escritos en el lenguaje de programación C con las interfaces de control y de visión incluidas como librerías.

Una de las características que se desea en las aplicaciones de control de tareas, es la capacidad de responder en tiempo real a los cambios que se presentan en un entorno dinámico. El manejo de eventos debe incorporarse como un mecanismo que permita a los módulos clientes disponer de la información más actualizada y enterarse de los eventos afectan al entorno.

Dentro del esquema los clientes son tanto consumidores de información de los servidores de visión, como proveedores de instrucciones para los servidores de control (Figura 3.8).

Cliente

Algoritmos de control programados

Redes Neuronales Lógica Difusa

3. Agentes Colaboradores

Manejo de Eventos

Figura 3.8 Diagrama de un módulo Cliente

49

Resulta adecuado contemplar un sistema operativo en tiempo real como QNX (véase sección 64, que facilite mecanismos de comunicación asíncrona, es decir, mecanismos para el manejo de eventos [MÁRQUEZl993][KUBITZl998]. Este sistema operativo permite que la comunicación entre clientes y servidores sea de lo más eficiente en términos computacionales.

3.10 Manejo de eventos

La arquitectura incluye un mecanismo de manejo de eventos el cual permita a los clientes reaccionar dinámicamente ante los cambios en el entorno. El manejo de eventos propuesto (figura 3.8) esta basado en el modelo de comunicación “aviso automático’’ (automatic push) expuesto por Kubitz [KUBITZ1998] . El cliente se suscribe al servidor, para ello utiliza send() y recibe una respuesta inmediata sobre la aceptación del modelo de comunicación. Entonces el servidor avisa a todos los clientes suscritos cada vez que nuevos datos estén disponibles. Los clientes obtienen entonces tales datos del servidor, usando la secuencia de comunicación send(), receive(), reply().

I‘

,’

i

Figura 3.9. Modelo de comunicación aviso automárico.

La ventaja de este modelo es que el cliente puede suscribirse a más de un servidor (recurso) y recibir los datos del servidor que entregue los datos primero. Además, el cliente no pierde ninguna notificación sobre nuevos datos de ningún servidor al que esté suscrito. Un cliente que esté recibiendo nuevos datos de un servidor conseguirá

50

’!

la notificación de un segundo servidor tan pronto como el cliente haya finalizado la comunicación con el primer servidor.

-1-

3.11 Conclusiones

En particular, el modelo cliente - servidor, base de la arquitectura propuesta en esta tesis, cumple cabalmente con los principios de una buena arquitectura [VAUGHN19941 lNATH19951 [KUBITZ1998]:

1. Consistencia: la arquitechra cliente - servidor esta bien fundamentada, bien soportada por la tecnología actual y su aplicación resulta bastante estable.

2. Ortogonulidad: los elementos de la arquitectura (clientes, servidores y recursos) son relativamente independientes unos de otros gracias a las capas de software intermedio, lo que facilita la portabilidad y la reusabilidad de los componentes.

3. Apropiada: la arquitectura cliente - servidor se enfoca a funciones bien definidas, cada servidor realiza una función especifica de atención a los clientes.

4. Parsimonia: la arquitectura cliente - servidor por su naturaleza distribuida evita la redundancia funcional entre sus partes (cada servidor se especializa en el acceso a un recurso especifico).

5. Transparencia: la arquitectura cliente - servidor, permite que los usuarios manejen un nivel elevado de abstracción en los clientes, ocultando la complejidad funcional de los recursos dentro de los servidores.

6. Generalidad: la arquitectura cliente - servidor cumple con múltiples propósitos de diseño: proporciona a los clientes acceso sencillo a cualquiera que sea el tipo de los recursos, permite especializar a los servidores para mejorar la administración de tales recursos y permite un crecimiento escalar de los sistemas.

7 . Abierta: la arquitectura cliente - servidor, al incorporar un mecanismo de manejo de eventos, esta diseñada para atender aquellos eventos de interés para el cliente. Además, su diseño modular le permite adaptarse a la disponibilidad de los recursos del usuario.

8. Completa: la arquitectura cliente - servidor resuelve las necesidades de integrar sistemas, así como de controlar y administrar los recursos de manera modular. Gracias a que se considera la comunicación entre los elementos por medio de interfaces, se facilita el diseño y la reutilización de los componentes para su aplicación en otros sistemas.

51

La arquitectura cliente - servidor ha sido probada con éxito en la integración de sewom para el control de actuadores en un robot móvil, donde demostró ser flexible y adaptable a una amplia variedad de protocolos de comunicación. Tales resultados alientan la idea de que la arquitectura cliente - servidor también resulte adecuada para incorporar a la visión artificial al control de robots articulados.

En este capítulo se definieron ciertas características de abstracción de datos y reusabilidad, buscando contemplarlas dentro del diseño de la arquiteciura de integración propuesta. Se presentó la arquitectura o esquema de integración basado en el modelo cliente - servidor, se describen los componentes y la relación funcional entre los servidores encargados de proporcionar la información visual, los servidores encargados de comunicarse con el controlador del robot y los clientes encargados de llevar la lógica del control. También se presenta un modelo para el manejo de eventos para agregar capacidad de respuesta a cambios dinámicos del entorno.

El modelo cliente - servidor ofrece características de independencia de los dispositivos de hardware y demás recursos, lo que permite que el desarrollador de aplicaciones se enfoque en el manejo de la información y en la lógica de la tarea.

52

CAPÍTULO 4

INTERFAZ PARA VISION

4 Interfaz para Visión

Para adquirir información desde un sistema de visión, los procesos de control (clientes) harán uso de un conjunto de llamadas a funciones propias de los servidores de visión. Tal conjunto de llamadas formaran la API (interfaz de Programas de Aplicación) del servidor de visión (véase figura 3.5). Se entiende que una interfaz proporciona un conjunto de definiciones de métodos o funciones.

4.1 Información visual

Antes de la definición de la interfaz propuesta para obtener información visual, se propone considerar los niveles de computación que un sistema de visión tiene que realizar para calcular las propiedades de un objeto [JAIN1995], con el objeto de determinar aquella información que resulte uta para las tareas de control que implican reconocimiento, localización y posicionamiento.

Una imagen podría contener muchos objetos y un sistema de visión artificial involucra calcular ciertas propiedades de un objeto, no la imagen como un todo. Para calcular las propiedades de un objeto en una imagen, se debe primero considerar los objetos individuales (ya segmentados) como objetos separados, entonces las características se pueden obtener aplicando operaciones a los objetos separados.

Considere cada algoritmo de visión en términos de sus entradas y salidas típicas, con la intención de caracterizar las operaciones, de tal manera que sea posible discutir la naturaleza de la información visual que sea requerida. Note que la entrada a un sistema de visión una imagen y la salida es una cantidad simbólica que denota la identidad o la ubicación de un objeto. La cantidad de datos procesados por un sistema de visión es muy grande, por lo que el requerimiento computacional también es grande.

53

Las operaciones en imágenes pueden clasificarse por niveles computaeionaks [JAIN1995], de acuerdo a los requerimientos de cálculo. En este sentido se tienen cuatro niveles:

1. Nivel de punto: donde se puede determinar, por ejemplo, si un pixel (elemento de imagen) pertenece a un objeto o pertenece al fondo de la imagen.

2. Nivel local: donde interviene una región local en la operación, por ejemplo un promediado de la imagen que use una máscara con vecindad local de 5x5 pixeles.

3. Nivel global: donde interviene la imagen completa. Por ejemplo calcular el histograma de una imagen o la operación de ecualizar la imagen.

4. Nivel de objeto: la mayoría de las aplicaciones de visión requieren que se 11 calculen propiedades a nivel de objeto, donde interviene sólo aquellos pixeles que pertenezcan a un objeto en particular. Por ejemplo calcular el área de un objeto.

Se propone que la información visual que manejen los procesos clientes encargados del control sea a nivel de objeto, y que la interfaz de visión este enfocada en manejar las propiedades a nivel de objeto.

4.2 Subtareas de los sistemas de vision

Una tarea común en manufactura industrial es la adquisición de partes (piezas u objetos), conocida como bin pick¿ng, la cual requiere desempeñar varias subtareas especificas [LOUGHEED1988], donde se implica la cooperación de un sistema de visión. Tales subtareas se enuncian a continuación:

1. Detección de partes. 2. Orientación de partes. 3. Determinación del punto de agarre. 4. Confirmación del punto de agarre y la orientación de la parte en la

herramienta de sujeción (gripper o pinza). 5. Inspección. 6. Determinación del punto de deposito. 7. Rastreo del punto de deposito en movimiento. 8. Colocación en la orientación apropiada

54

Ahora se hará un análisis de la utilidad de la infamación visud y de manera Paulatina se Presentará la definición de la interfaz para la visión, utilizando un formato basado en el lenguaje de programación c.

4.3 Detección de partes.

El objetivo de esta función es saber si un determinado objeto esta presente y cual es su ubicación, de tal forma que se podrá preguntar al servidor de visión: jestá presente el objeto idobjeto en el área de trabajo?

int localiza~objeto(id~ob~eto, x, y, z ) int id-objeto; / * identificador del objeto a localizar * / int *x, *y, * z ; / * coordenadas de la localización del objeto * /

II

La llamada a la función localizaobjeto() del servidor de visión deberá regresar un valor de verdadero cuando el sistema de visión identifique un objeto de la clase id-objeto, al regreso de la llamada los parámetros x y z indicarán las Coordenadas de la ubicación del objeto (centro de masa) en el área de trabajo. La función devolverá un valor de falso en caso de que el sistema de visión no localice ningún objeto de tal clase.

Sí lo que interesa es saber si hay un objeto en una ubicación especifica del área de trabajo, se podría llamar a la función cualobjeto(), tal llamado deberá recibir en x y z la ubicación (región) en la cual se esta interesado.

int cual-objeto(id objeto, x, y, z ) int *id obieto: I* identificaáor del objeto por detectar * /

- 2 ~~

int x, y, z ; / * coordenadas de la localizáción del objeto * /

AI regreso de la llamada, la función cual-objeto() deberá devolver un valor de verdadero sí el sistema de visión detecto un objeto distinto al fondo en tales coordenadas y en id-objeto la clase a la cual pertenezca el objeto. La función devolverá un valor de falso en caso de que se detecte fondo o un valor indefinido o nulo en caso de que el objeto que se detecte no pertenezca a ninguna de las clases conocidas'.

' Se asume que el sistema de visión cuenta con una base de conocimiento donde se encuentra los identificadores y la descripción de las clases de objetos (piezas o partes) con las que se esta trabajando.

55

4.4 Orientación de partes.

El objetivo de esta función es conocer el ángulo del eje pr¡ncipd de un objeto en una imagen proporciona una orientación estándar para los objetos. Un proceso cliente podría consultar a un servidor de visión para saber la orientación de un objeto que se encuentre en el área de trabajo.

float orientacion-objeto(id-objeto, x, y, z)

int x, y, z ; int id-objeto; / * identificador del objeto referido */ i(

/* coordenadas de la localización del objeto * /

La llamada a la función orientacionpbjeto() recibirá en x y z las coordenadas de la

pertenece. AI regreso de la llamada la función deberá devolver un valor entre O y 180 para indicar el ángulo del eje principal del objeto con respecto al eje Y. Un valor nulo o indefinido indicará que hubo un error en el cálculo de la orientación del objeto.

localización del objeto (centro de masa) y en id-objeto se indicará la clase a la cual 5 1

4.5 Determinación del punto de agarre.

El objetivo de esta función es saber las coordenadas para poder sujetar una pieza. Para conocer la orientación de la pieza se usaria la función orientocion-objeto() (sección 4.4). Un proceso cliente podría preguntar a un servidor de visión: ¿Dónde se encuentra la herramienta de sujeción? Para lo cual servirá la siguiente llamada:

int localiza-gripper(id-gripper, x, y, z, roll, pitch, yaw) int id-gripper; / * identificador de clase de la herramienta * / int *x, *y, *z; / * coord. de localización de la herramienta * / int *roll, *pitch, *yaw; / * ángulos de orientación * /

La función localiza-gripper() recibirá en el parámetro id-gripper la identificación de la clase o tipo de herramienta de sujeción' [GROOVER1986]. AI regresar la llamada devolverá el valor de verdadero si hubo éxito en la localización de la herramienta y la coordenada de su ubicación vendrá indicada en los valores de x, y, z. La función devolverá un valor de falso en caso de no localizar el efector (gripper) dentro del área de trabajo.

También llamada end effector. Existen vanos tipos: mecánicos, magnéticos, ventosas, adhesivos, garfios, cucharas, herramientas para soldar, para pintar, pulir, perforar, para cortar con agua a chorro, antorchas, etc.

56

Además podría consultarse al servidor de visión para saber cual es el punto principal de sujeción de una pieza en especial, considerando que el efector es una pinza.

int punto-agarre(id ,objeto, x, y, z , roll, pitch, yaw) int id-objeto; int *x, *y, * z ; / * coordenadas del punto de agarre * / int *roll, *pitch, *yaw; / * ángulos de orientación * /

/" identificador de clase del objeto * /

En la llamada a punto-agarre() el parámetro id-objeto sirve para indicar la clase de objeto que se quiere sujetar, por medio de las coordenadas x, y, z> se enviará la ubicación del objeto referido. AI regresar la llamada devolverá un valor de verdadero si tiene éxito y proporcionará en x, y, z, las coordenadas del punto de sujeción para tal objeto. La función devolverá falso en caso de que el sistema de visión no logre detectar el punto de sujeción.

'I

4.6 Confirmación del punto de agarre.

El objetivo de esta función es validar que la herramienta de sujeción (gripper o pinza) efectivamente sujete la pieza y coofirmar la correcta orientación de la pieza en la herramienta de sujeción.

Figura 3.8. La geometría usada para alinear puntos.

/I

57

Esta subtarea podría implementarse como el conjunto de las primitivas de posicionamiento descritas por Hager [HAGER1997] como posicionamiento punto a punto, punto a linea y línea a punto, las cuales son vistas como funciones de error en la imagen (una biblioteca de algoritmos para realimentación al control con funciones para definir requisitos cinemáticos en el espacio de la tara). Es decir, se definen los puntos en la imagen de los objetos que interesa alinear o posicionar por medio de una primitiva de posicionamiento y esta indicará por medio de un error (basado en la posición de los puntos en la imagen captada) lo que falta para lograr la posición deseada para tales puntos. El error disminuirá conforme se alcance la posición requerida y tendrá valor de cero cuando se logre el objetivo. Se asume que el sistema de visión es capaz de rastrear los punto definidos en la imagen.

Por ejemplo, dos primitivas punto a línea pueden ser combinadas (véase figura 3.8) para realizar tareas complejas de posicionamiento, como la alineación de dos objetos cuadrados (tales como dos floppies), buscando que se toquen en una de sus esquinas, tal configuración puede lograrse usando tres esquinas de cada disco.

II

La primitiva de posicionamiento punto a punto podría tener una definición como la que se propone a continuación (se define una estructura para el tipo de dato ‘punto’, para facilitar el manejo de los datos de localización):

punto *puntogunto(id-objeto, p, id-gripper, s) int id objeto; / * identificador de clase objeto-objetivo * / punto p; / * punto de referencia fijo objeto-objetivo * / int id-gripper; / * identificador de clase de la herramienta * / punto s; / * punto asociado a la herramienta agarre * /

typedef struct { / * estructura para dato de localización * / int x, y, z ; / * coordenadas del punto * / int roll, pitch, yaw; / * ángulos de orientación * / ) punto;

La llamada a la función punto-punto() debe recibir la clase a la cual pertenece el objeto como parámetro en idobjeto y en el parámetro p la coordenada del punto de referencia al objeto (coordenadas de imagen), definida como la posición del punto objetivo. AI mismo tiempo p puede servir para indicar la ubicación del objeto y diferenciarlo de otros en el espacio de trabajo.

El tipo de herramienta de agarre se indicará en idsripper y en s las coordenadas del punto asociado a la herramienta, este es el punto que se desea alcance la posición del punto objetivo.

AI regreso de la llamada la función devolverá un apuntador a una estructura de tipo punto que representa al error en las coordenadas, es decir, cuanto falta para que el punto s tenga las mismas coordenadas del punto p.

La primitiva de posicionamiento punto a línea podría tener una definición como la siguiente:

58

Punto *Punto-linea(id-objeto, p, q, .id-gripper, s ) int id-objeto: Punt0 P, q; int id-gripper; punto s;

/ * identificador de clase del objeto-objetivo * / / * Puntos fijos de referencia al objetivo * / / * identificador de clase de la herramienta * / / * punto asociado a la herramienta agarre * /

ii

Donde se deberá incluir en la llamada apunto-Zineu() la clase del objeto en id-objeto y las coordenadas de dos puntos,p y q (en coordenadas de imagen) para hacer referencia a una línea imaginaria que servirá como objetivo (pudiera ser el eje principal del objeto). En el parámetro idjripper se indicaría el tipo de herramienta que esté usando el manipulador y en s el punto de la herramienta que se busca alinear con la línea imaginaria descrita por los puntosp y q. AI regreso de la llamada, la función devolverá un apuntador a una estructura punto con el valor del error en las coordenadas de la posición basado en la imagen.

La primitiva de posicionamiento línea a punto podría tener una definición como esta:

punto *lineagunto(id-objeto, s, id-gripper, p, q) int id-objeto; / * identificador de clase del objeto-objetivo * / punto s; /*',punto de referencia fijo objeto-objetivo * / int id-gripper; / * identificador de clase de la herramienta * / punto p, q; / * puntos asociados a la herramienta * /

La función Zineugunto() recibirá la clase del objeto que se define como objetivo en id-objeto y el punto de referencia establecido como punto objetivo en s. El tipo de herramienta utilizada por el manipulador será indicado por el parámetro dxripper. Con los valores de p y q se definirá una línea imaginaria sobre la herramienta. AI regreso de la llamada, la función devolverá un apuntador a una estructura de tipo punto con el valor del error en las coordenadas de la posición basada en la imagen, donde' lo que se busca es posicionar la herramienta del manipulador tal que los puntos p, q y s sean colineales, en otras palabras, cuanto falta para que los puntosp y q estén alineados con el punto s.

4.7 Inspección.

Determinar si una pieza cumple con las especificaciones de calidad como longitud, diámetro, color, textura, limpieza, número de componentes, número de hoyos, etc. Para una tarea de inspección se podría especializar a un servidor de visión que facilite la información procesada por un sistema de visión diseñado para localizar y contar hoyos y posiblemente otro tipo de componentes, basándose en la localización de componentes conexas, el color y la textura de tales componentes. Una componente conexa es una región en una imagen, donde los pixeles que la integran están conectados en algún sentido, generalmente los niveles de brillantez de los pixeles satisfacen un criterio especificado de similitud, como los que se exponen en [GONZALES19871 y [HARALICK1992].

59

Se propone definir el siguiente conjunto de funciones para proporcionar la información visual a los clientes que facilite el control en tareas de inspección de calidad

La longitud puede definirse cómo la extensión del eje principal del objeto en cuestión [PARKER1994].

unsigned float longitud(id-objeto, x, y ) int id-objeto; int x, y; / * puntos del centro de masa (centroide) */

/ * identificador de clase del objeto-objetivo * /

La llamada a la función longitud() recibirá en g-objeto el tipo de objeto al que se hace referencia (pudiendo ser un valor nulo). En los parámetros x y se debe indicar la coordenada del centroide del objeto. AI regresar la Uamada deberá devolver un valor flotante positivo correspondiente a la longitud del eje principal (eje mayor) del objeto. Un valor de nulo, al regreso de la función, indicará un error en cálculo de la longitud.

El diámetro puede definirse como la extensión del eje mínimo (lo ancho del objeto) [PARKER1994].

unsigned float diárnetro(id-objeto, x, y ) int id-objeto; / * identificador de clase del objeto-objetivo * / int x, y; / * puntos del centro de masa (centroide) * /

La llamada a la función d%meh.o() deberá recibir en d-objeto el tipo de objeto al que se hace referencia (pudiendo ser un valor nulo). En los parámetros x y se debe indicar la coordenada del centroide del objeto. AI regresar la Uamada deberá devolver un valor flotante positivo correspondiente al diámetro del eje menor (eje m’nimo) del objeto. Un valor de nulo, al regreso de la función, indicará un error en cálculo del diámetro.

El histogrurnu9 de los pixeles de un objeto muestra la distribución de la brihntez (niveles de gris o colores) encontrada en tal objeto. Medidas estadísticas de la brillantez hechas a partir del histograma pueden ser Útiles para definir atributos como el color, la textura y la limpieza de un objeto.

El color de un objeto puede definirse como el valor promedio de los niveles de brillantez en el histograma del objeto [BAXES1994]. Se define una estructura para el tipo de dato ‘color’ para facilitar su manejo:

color *obten-color(id-objeto, x, y, z)

El histogram de una imagen (o región de ella) es una gráfica de la distribución de los niveles de brillantez y proporciona una descripción global de la apariencia de la imagen (oscuridad, brillantez, bajo y alto contraste).

9

60

int id-objeto; int x, y , z ;

typedef struct ( /* tipo de dato color formato RGB * / int rojo; / * nivel de rojo (red) * / int verde; / * nivel de verde (green) * / int azul; / * nivel de azul (blue) * / ) color;

/ * identificador de clase del objeto-objetivo * / / * coordenada del centro de masa del objeto * /

La llamada a la función color() podrá recibir opcionalmente en id-objeto el tipo de objeto que se analiza y en los parámetros x, y, z las coordenadas del centro de masa del objeto en cuestión. AI regreso de la llamada retornara un tipo de dato ‘color’ del objeto. Un valor de nulo indicará que hay un error en la función.

La textura (superficie) de un objeto se puede clasificar como áspera o suave [BAXES1994]. Una manera conveniente para determinar la textura de un objeto es examinar la frecuencia espacial (variación de la brillantez) contenida en su imagen. Una textura suave tiene pocas variaciones en su brillantez, lo cual es equivalente a tener principalmente frecuencias espaciales bajas. Una textura áspera tiene muchas pequeñas variaciones de brillantez, lo cual significa que contiene frecuencias espaciales altas. Puede usarse un filtro de pasa alto o una transformada de Fourier para detectar las altas frecuencias. Algunas veces, sólo obtener la desviación estándar de la brillantez en un objeto es suficiente para determinar su textura. Debido a que la desviación estándar es una medida de la variación de los niveles de brillantez con respecto a la media, un valor alto indica muchas variaciones y por lo tanto una textura áspera, similarmente un valor bajo a menudo indica una textura suave rBAXES19941.

double textura(id-objeto, x, y , z) int id-objeto; int x, y, z; / * coordenadas del centroide del objeto * /


La llamada a textura() recibirá en id-objeto el tipo de objeto al cual se hace referencia, en los parámetros x, y, z, se deberá enviar las coordenadas de centro del objeto. AI regreso, la llamada devolverá un valor correspondiente a la frecuencia espacial contenida en la imagen del objeto, donde un valor pequeño señala una textura suave y un valor alto indica una textura aspera. Un valor nulo indicará que hubo un error en la llamada a la función.

Existen aplicaciones de inspección donde es necesario contar componentes (piezas u objetos). Un componente puede ser visto como un objeto o patrón y tener un identificador y una descripción, como lo tienen cualquiera de los objetos contemplados dentro de una base de conocimiento para un sistema de visión.

int cuenta-componentes (id-objeto, x1, yl, x 2 , y2) int id-objeto; int xl, yl, x2, y2 ; / ? region de la imagen a inspeccionar * /


61

La llamada a cuentaconponentes() deberá recibir en el parámetro id-objeto el tipo de componente (patrón) a contabilizar, los argumemtos XI, y I , x2, y2, definen la región de la imagen a inspeccionar. Al regreso la llamada deberá devolver el número de componentes localizados en la imagen. La función devolverá el valor de nulo en caso de ocurrir un error en la llamada a la función. ,

4.8 Determinación del punto de depósito.

El objetivo de esta función es conocer cual es la ubicación donde se debe depositar una pieza. Podría consultarse ai senidor de visión para obtener las coordenadas de localización del punto en el cual depositar un objeto.

int deposito(id-objeto, x, y., z , roll, pich, yaw) int id objeto: I* identificador de clase del objeto-objetivo * / - - int *x, *y, * z ; I* coordenadas para depositar el-objeto-*/ int *roll, *pitch, *yaw; / * ángulos de orientación *I

La función depósito() deberá recibir en el parámetro id-objeto el tipo de objeto que se pretende depositar. AI regreso la llamada deberá devolver en los parametros x y z las coordenadas del contenedor o lugar para depositar el objeto. La función devolverá el valor de verdadero cuando haya éxito en localizar las coordenadas del deposito y un valor de falso cuando no se localice.

4.9 Rastreo del punto de depósito en movimiento.

El objetivo de esta función es realizar un seguimiento de la ubicación de objetos dinámicos en general. La reciente introducción de sistemas de procesamiento de imágenes con velocidad en tiempo real y de bajo costo, permiten la integración ,eficiente de información visual en el ciclo de reaiimentación de un sistema robot [NELSON1996], lo cual incrementa la flexibilidad de los robots al permitir rastrear objetivos visualmente, es decir, seguir el movimiento de objetos en el área de trabajo.

En realidad, lo que hace un sistema de visión para seguir un objetivo en movimiento, es rastrear algunas de sus características (típicamente esquinas) en la imagen, midiendo el movimiento de tales características de manera continua y rápida. Las características del objetivo que serán rastreadas pueden seleccionarse por un usuario o por un algoritmo de selección, que busque las características con gradientes de fuerte intensidad en direcciones perpendiculares, como resultan ser las esquinas de los objetos.

Una posible definición de la llamada para rastrear objetivos es la que se propone a continuación:

62

int rastrearíid-objeto, x , y, z, roll, pich, yaw) int id-objeto; int *x, *y, * z ; / * coordenadas de la ubicación del objeto * / int *roll, *pitch, *,yaw; / * ángulos de orientación * /


Donde la llamada a la función rastrear() deberá recibir en zü-objeto el tipo de objeto que se pretende seguir, y en los parihetros x, y, z las coordenadas de ubicación del objeto. AI regresar la función deberá devolver en x, y, z la nueva ubicación del objeto. Un valor de retorno de verdadero indicará éxito en el rastreo y un valor de falso indicará que no fue posible realizar el rastreo.

4.10 Colocación en la orientación apropiada.

El objetivo de esta función es poder regular la orientación de los objetos que son manipulados en una tarea. Para controlar visualmente un robot manipulador que sostenga a una pieza, el objetivo es mover las coordenadas de un punto 'P hacia alguna ubicación en el plano de la imagen, controlando el movimiento del punto 'P [NELSON1996]. Típicamente, el punto 'P es alguna característica de un objeto que esta siendo sostenido por el manipulador. Así, el movimiento del punto 'P es inducido con relación a la posición de la herramienta del manipulador que esta siendo observada. La figura 3.9 muestra el sistema de coordenadas usado para definir el mapeo desde el espacio de la tarea al espacio del sensor, donde el punto 'P es definido con respecto al estado de la tarea como el punto TP en coordenadas de la tarea.

Plano de Coordenadas

Espacio de la tarea

Figum 3.9. Mapeo enbe el espacio de la tarea y el plano de la imagen.

Las funciones definidas en el punto 4.6 de este capítulo pueden servir para controlar y regular la orientación y la posición de objetos que estén siendo sujetados por un robot manipulador [HAGER1997] (véase sección 2.6).

I

63

La primitiva para conocer el error de posicionamiento en la orientación solicitada podría tener una definición como la siguiente:

punto *position-alineada(id-objeto, id-gripper, p, s , t, L, M) int id-objeto; int id-gripper; punto p, s , t; / * puntos fijos de referencia al objetivo * / linea L; / * linea de referencia asociado a herramienta * / linea M; / * linea de referencia asociado a herramienta * / typedef struct( punto a; unto b; P 1 inea ;

/ * identificador de clase del objeto-objetivo * / / * identificador de clase de la herramienta * /

li

Donde se deberá incluir en la llamada a posicwnalineada() la clase del objeto en kf-objeto y las coordenadas de los puntos de referencia p , s y t, m á s las lineas L y M (en coordenadas de imagen) para hacer referencia a las línea imaginaria que servirán como referencias al objetivo (pudieran ser los ejes principales del objeto). En el parámetro kf-gripper se indicaría el tipo de herramienta que esté usando el manipulador. AI regreso de la llamada, la función devolverá un apuntador a una estructura punto con el valor del error en las coordenadas de la posición basado en la imagen. 11

4.11 Conclusión

En este capítulo se definió la interfaz propuesta como un conjunto de funciones para la adquisición de información visual, tal interfaz esta enfocada en proporcionar a los

frecuentemente requerida en tareas de inspección, reconocimiento, ubicación, agarre y posicionamiento de partes.

Dentro del esquema de integración, se propone utilizar la interfaz de visión junto con la interfaz de control (capítulo S), para integrar dentro de un módulo cliente toda la información requerida para realizar el control mediante visión artificial de un robot, como quedo definido en el capítulo 3.

clientes (definidos en la sección 3.9) la información visual de los objetos más I

64

CAPÍTULO 5

INTERFAZ PARA CONTROL DEL ROBOT

'I/

5 Interfaz para Control del Robot It

En gran medida, la programación de robots consiste en 'enseñar' al robot su ciclo de irubujo. Una gran parte de un programa para robot implica las rutas de los movimientos que se deben ejecutar para mover piezas o herramientas desde una localización a otra en el espacio de trabajo. Sin embargo, hay partes del programa que no involucran ningún movimiento del robot, pero si involucran la interpretación de datos de los sensores, enviar y recibir señales de otros dispositivos, así como realizar cálculos y decisiones sobre el ciclo de trabajo.

En este capítulo se definen las interfaces que permitirán realizar el control sobre los movimientos de un brazo robot. Recuerde que una interfaz proporciona un conjunto de definiciones de métodos.

El estudio realizado para determinar las principales funciones requeridas para dar versatilidad a las tareas se basó en lenguajes de robots comerciales [GROOVER1986] como VAL 11, RAIL, AML y RALP I1 rCRS19941.

I

5.1 Características de los lenguajes de robots

Los lenguajes modernos para la programación de tareas de robots manipuladores comparten las siguientes características y capacidades [GROOVER19861:

65

1. Conh’oZ de movimiento: esta característica incluye la habilidad para definir movimientos del manipulador, utüizando enunciados para definir la secuencia de movimientos y localizaciones. I/

2. Capacidades avanzadas de sensores: incluye la capacidad de atender señales binarias externas y el control de dispositivos por medio de la información de sensores externos (por ejemplo sensores de proximidad).

1 3. ZnteZigenciu Zimiiada: esta es la habilidad de utilizar la información recibida sobre el entorno de trabajo para modificar el comportamiento del sistema de una manera programada.

4. Comunicaciones y procesamiento de datos: cuentan con la capacidad de interactuar con computadoras y bases de datos para el propósito de llevar registros, generar reportes y controlar actividades en celdas de trabajo.

Como se muestra en la figura 5.1, los lenguajes de programación de robots deben ser capaces de controlar al robot manipulador, de interactuar con dispositivos periféricos, como son los sensores, y soportar la comunicación de datos con otros equipos de cómputo.

Lenguaje de programació -

POSici0”es ACCi0”W secuencia y lógica

Sistema los . . .. . . .

operativo Controlado r del robot

Modo monitor Modo editor Modo ejecución A Periféricos

Robot

Figura 5.1 Diagrama de un sistema robot mostmndo la coordinación de SUI componentes por medio del lenguaje.

66

5.2 Funciones de los lenguajes para robots

Existen elementos y funciones de los lenguajes de programación de robots que deben ser incorporados en la interfaz oprotocob de control para permitir la realización de tareas de mediana y alta complejidad:

,I

1. Constantes, variables y otros datos. 2. Comandos de movimiento. 3. Comandos de sensores y efectores. 4. Cálculos y operaciones. 5. Programa de control y subrutinas. 6. Comunicaciones y procesamiento de datos. 7. Comandos en modo monitor.

Para la definición de las interfaces se empleará una notación basada en el lenguaje de programación C. Se propone el lenguaje C debido a que el robot CRS modelo T476 con que cuenta el Cen'det permite desarrollar programas en este lenguaje.

5.3 Constantes, variables y otros datos IO

Como se expone más adelan@ en el capítulo 5, se propone emplear el lenguaje C para la programación de los procesos clientes, lo cual permitirá emplear las capacidades propias del lenguaje C para definir constantes, variables y estructuras de datos. Lo que sí será necesario es una forma para definir variables de localizaciones (una posición en el área de trabajo almacenada en coordenadas cartesianas).

POZNR En los lenguaje de programación de robot es común este comando, el cual define una variable como la localización de un punto. Una localización cartesiana requiere seis valores: Las coordenadas x, y, z y los ángulos en grados yaw, pitch, roll, de la herramienta del brazo manipulador.

Para la definición de una localización en el lenguaje C, se hará uso de una estructura que contenga los seis valores, además de un nombre que sirva para identificar la localización:

typedef struct (

I

char *variable;" / * nombre de la variable * / float x, y , z ; , / * coordenadas del punto * / float roll, pitch, yaw; / * ángulos de orientación * /

) posicion; 'I/

Una variable de localización se asignaría de la siguiente forma:

posicion *Al = definegosicion(nombre, II x, y, z , roll, pitch, yaw) ;

67

La definición de la función es la siguiente:

posicion *definegosicion(nombre, x, y, z , roll, pitch, yaw) char *nombre; / * nombre de la variable * / float x, y, z , roll, pitch, yaw: I * coordenadas y angulos * /

La llamada a la función definegunto(), recibirá como parametros el nombre para la variable y los seis valores de la localización. La función deberá regresar un apuntador a una estructura de tipoposicion. Como resultado de llamar a la función, se tendrá en la memoria del controlador una variable de localización. En caso de que falle la llamada la función devolverá un valor nulo.

ACTUAL: este comando permite leer la posición actual del brazo robot, almacenando la información como una entrada en la tabla de localización en memoria. La localización es almacenada en forma cartesiana (x, y, z, yaw, pitch, roll). Este comando es usado para determinar el error en la posición, de tal manera que pueda ajustarse.

La definición de una función que soporte el comando ACTUAL puede ser:

posicion *position-actual(char *nombre);

La llamada a la función gosicion-uctuuZ() recibirá como parámetro el nombre para la localización que se obtenga. La llamada deberá retornar un apuntador a una estructura de tipo posicion conteniendo los datos de la localización registrada. En caso de fallo en la llamada retornará un valor nulo.

5.4 Comandos de movimiento

Entre las funciones más importantes en un lenguaje de programación de robots, están las de control del movimiento:

HUME este comando aünea el brazo con el modelo matemático almacenado en la memoria del controlador. Cuando el robot se enciende, no conoce su posición relativa al mundo. Se debe utilizar este comando para permitir la sincronización entre el controlador y el brazo robot.

Es necesaria la definición de funciones que inicien y terminen la actividad del robot, para permitir la sincronización del robot con su controlador, así como la del servidor de control del robot:

int inicializar-robot(int id-robot) ; / / activa servidor de control int finalizar-robot(int id-robot) : / / desactiva servidor de control

68

81 Las llamadas a inicializur-robot() y finaZizar-robot() deberán recibir como parámetro un identificador del robot que se pretende controlar. AI regreso, ambas llamadas devolverán un valor,de verdadero si tuvo éxito, y un valor de falso en caso de fallo.

MOVE: este comando causa que el efector del brazo se mueve desde su posición actual hasta un punto previamente defhido. El punto debe ser definido en coordenadas del robot, esto es, en coordenadas cartesianas (x, y, 5 pitch, yaw, roll) vistas anteriormente.

Para la definición de una función que soporte al comando MOVE, se hará uso de la estructura posicion definida anteriormente y se introducirá un nuevo parámetro nombrado recta, el cual puede tomar el valor de verdadero cuando se pretenda que el controlador del robot calcule una trayectoria en línea recta desde la posición actual del manipulador hasta el punto definido por vurqunto, ocasionando que el brazo robot siga tal trayectoria. Si no se requiere una trayectoria en línea recta, el valor para el parámetro recta deberá ser de falso.

int traslada(posici0n * v a r g u n t o i , i n t r e c t a ) ; I1

La función traslada() deberá regresar un valor de verdadero cuando tenga éxito la llamada y un valor de falso cuando falle.

En algunos casos, la trayectoha debe ser controlada de tal manera que el efector pase a través de algún punto intermedio. Este punto intermedio es referido como punto via. La necesidad de tales puntos Vía surge cuando existen obstáculos que deben considerarse al hacer el movimiento.

int traslada-via(posicion * p u n t o- d e s t i n o , p o s i c i o n *punto- via) ;

La función traslada-via() le indicará al controlador del robot que mueva el efector al punto definido porpunto-destino, pero pasando por el punto definido porpunto-via. La función trasúula-via() deberá regresar un valor de verdadero cuando tenga éxito la llamada y un valor de falso cuando falle.

I'

APPRO y DEPART: Una secuencia de movimientos relacionados puede incluir acercarse hacia un punto y alejarse de un punto. Esta situación surge en aplicaciones de manejo de materiales, donde es necesario que la pinza del manipulador se mueva hacia una localización intermedia sobre la parte antes de proceder a sujetarla. Esto es lo que se conoce como acercamiento (approach). El comando APPRO causa que el efector se acerque encima de un punto, a lo largo del eje Z en dirección negativa al punto, y quede a una distancia determinada en pulgadas. El comando DEPART, causa que el robot se aleje del su posición actual, a

69

lo largo del eje Z, a una distancia determinada en pulgadas, centímetros O milímetros de acuerdo a las características de robot.

La función de acercamiento del manipulador a un punto objetivo se puede definir como sigue:

int aproxima (posicion *punto-objetivo, int distancia) ;

La llamada a la función aproxima() deberá recibir como parámetros un apuntador a la variable de localización punto-objeh'vo, definida previamente mediante la función definejunto(), y una variable distancia indicando la distancia entre el efector y el punto objetivo definido por punto-objetivo. AI regreso de la llamada la función devolverá un valor de verdadero si tuvo éxito. o un valor de falso en caso de fallo.

La función para alejar el manipulador de su posición actual se puede definir como sigue:

int aleja-efector(int distancia) ;

La llamada a la función aleja-efector() deberá recibir como parámetro un apuntador a una variable distancia indicando la distancia a la que deberá retirarse el efector. AI regreso de la llamada la función devolverá un valor de 1 si tuvo éxito, y un valor de O en caso de fallo.

SPEED: este comando es usado para definir la velocidad con la que el brazo robot se moverá en los movimientos subsecuentes. El valor de la velocidad corresponde a un porcentaje de la velocidad máxima. El rango permitido varia desde 1% a 100% de la velocidad total, por lo regular el valor por defecto es 10%.

La definición de la función para controlar la velocidad del manipulador desde un programa en lenguaje C es la que sigue:

int velocidad(unsigned int vel) ;

Esta deberá ser llamada indicando en el parámetro vel un valor entre 1 y 100, correspondiente al porcentaje de la velocidad que será empleada para que el manipulador realice sus movimientos. AI regreso de la llamada la función devolverá un valor de verdadero si tuvo éxito, y un valor de falso en caso de fallo.

HERE: este comando permite definir la posición actual del efector del robot como una localización. La localización se almacena en forma cartesiana (x, y, z, pitch, yaw, roll). La función para el comando HERE se define haciendo uso de la estructura punto descrita anteriormente.

IO

posicion *registra$osicion-efector (char *nombre-variable) ;

La Uamada a la función regisiraposicion-e~e~~orefectoro recibe el nobre de la variable que registrará la posicion y deberá retornar un apuntador a una estructura de tipo posicion que contenga la información de las coordenadas actuales del manipulador. En caso de fallo deberá retornar un valor nulo.

JOG: este comando permite mover el efector del robot mediante incrementos artesianos especificados en pulgadas o milímetros. Opcionalmente, el movimiento se realiza en línea recta y siempre que sea posible, se mantiene la orientación de la pinza (gripper). Este comando es muy útil para ajustar la posición del efector del robot. La definición de una función que soporte el comando JOG puede ser la siguiente:

int ajustargosicion(x, y, z , recta) float x, y, x; / * incrementos en coordenadas cartesianas * / short recta; / * si valor = 1, mueve en línea recta * /

II

La llamada a la función ajustarjosicwn() deberá recibir como parámetros los incrementos en las coordenadas n, y, z, en el parámetro recta un valor de verdadero (1) si se desea que el movimiento sea realizado en línea recta, o un valor de falso (O) para indicar una interpolación de las articulaciones. AI regreso de la llamada la función devolverá un valor de verdadero si tuvo éxito o un valor de falso en caso de fallo.

. .

X, Y, Z: estos son tres comandos que permiten mover al robot mediante incrementos especificados en pulgadas o milímetros, manteniendo la orientación de la pinza cuando sea posible. Opcionalmente, el movimiento se solicita en línea recta. La definición para tales comandos puede ser la siguiente:

int ajustar-ejeX(int incremento, short recta) ; int ajustar-ejeY (int incremento, short recta) ; int ajustar-ejeZ(int lincremento, short recta) ;

La llamada a cualquiera de ih tres funciones deberá recibir como parámetro el incremento (o decremento en caso de un valor negativo) en la coordenada respectiva, en el parámetro recta un valor de verdadero (1) si se desea que el movimiento sea realizado en línea recta, o un valor de falso (O) para indicar una interpolación de las articulaciones. AI regreso la función devolved un valor de verdadero si tuvo éxito o un valor de falso en caso de failo.

ROLL, PITCH, YAW estos son tres comandos que permiten mover el efector del robot mediante incrementos especificados en grados de rotación sobre los ejes X,

71

XY, Z, respectivamente. Opcionalmente, el movimiento se hace en línea recta. El punto central del efector se mantiene en la misma posición siempre que sea posible.

La definición para tales'comandos puede ser la siguiente: . . * , ,

int rotar efectorX(int inc, short recta); /*rotación sobre el eje x roll * / int rotarIefectorXYíint inc, short recta);/*rotación sobre el plano XY picth*/ int rotar-efectorZ(int inc, short recta): /* rotación sobre el eje Z yaw */

NI La llamada a cualquiera de las tres funciones deberá recibir como parámetro el incremento 'en la rotación (o decremento en caso de un valor negativo) sobre el eje respectivo, en el parámetro recta un valor de verdadero (1) si se desea que el movimiento sea realizado en Línea recta, o un valor de falso (O) para indicar una interpolación de las articulaciones. AI regreso la función llamada devolverá un valor de verdadero si tuvo éxito o un valor de falso en caso de fallo.

5.5 Comandos de efectores

En la mayoría de los lenguajes para robots, existen comandos para ejercer un control sobre la operación de la pinza o efector (gripper).

OPEN. este comando abre la pinza y de manera opcional lo hace con la fuerza especificada, la cual es un porcentaje de la fuerza máxima de la pinza. Se define la función para el comando OPEN:

int abrir-efector(unslgned m t fuerza);

La llamada a abri-efector() recibirá como parámetro un valor enfuenu indicando el porcentaje (entre 1 y 100) de fuerza requerido al abrir la pinza. Ai regreso de la llamada la función devolverá un valor de verdadero si tuvo éxito o un valor de falso en caso de fallo.

CLOSE: este comando cierra la pinza y de manera opcional lo hace con la fuerza especificada, la cual es un porcentaje de la fuerza máxima de la pinza. La definición respectiva para el comando CLOSE:

int cerrar-efector(uns1gned int fuerza);

La llamada a cierra() recibirá como parámetro un valor en fuerza indicando el porcentaje (entre 1 y 100) de fuerza requerido al cerrar la pinza. AI regreso de la llamada la función devolverá un valor de verdadero si tuvo éxito o un valor de falso en caso de fallo.

72

5.6 Cálculos y operaciones aritméticas I

Las necesidades de realizar cálculos aritméticos y otro tipo de operaciones con valores de constantes, variables y otros datos surge en muchos programas de robots. La realización de tales operaciones se facilitará mediante el uso de las capacidades incluidas en el lenguaje C. 11

5.7 Secuencia de control y subrutinas I

En los programas de robots a menudo es necesario controlar la secuencia en la cual las ordenes son ejecutadas mediante bifurcaciones, ramificaciones, flujos de control y mediante el uso de subrutinas. De igual forma, el emplear las capacidades del lenguaje C facilitará el control en la secuencia de las ordenes transmitidas al controlador del robot.

1

li

5.8 Comunicaciones y procesamiento de datos I

Aquí se hace referencia a las comunicaciones entre el sistema robot y el operador, sus dispositivos periféricos o algún otro sistema de computo. La capacidad del robot para comunicarse con el operador le permite solicitar información, indicar el origen de un mal funcionamiento o informar al operador sobre lo que se esta realizando. Nuevamente, hacer uso de las capacidades del lenguaje C facilitará realizar la comunicación entre el robot y el operador, así como facilitar el procesamiento de datos con otros sistemas y dispositivos periféricos. Esta es la principal razón por la que se propone usar al lenguaje C, por su capacidad y sus recursos para realizar comunicaciones. Tales recursos serán presentados en el capítulo 6 que estudia los Mecanismos de Integración.

5.9 Comandos en modo monitor

El modo monitor sirve para realizar funciones tales como la de introducir localizaciones por medio de una botonera (teach pendant) y definir la velocidad inicial para la ejecución de un programa. Varias funciones relacionadas con la supervisión del sistema, el procesamiento de datos y las comunicaciones son realizadas con comandos del modo monitor. Los comandos monitor más comunes son: EDIT que permite la edición de un programa; EXIT que guarda el programa editado en la memoria del controlador; STORE que guarda un programa a disco; READ que lee un archivo de programa almacenado en la memoria del controlador; LIST despliega el contenido de los archivos de programas; PRINT imprime un archivo de programa; DIRECTORY lista los archivos de programas; DELETE borra un archivo de programa; EXECUTE sirve para ejecutar un programa; STOP

73

detiene la ejecución de un programa. Estos comandos son específicos al sistema operativo del controlador del robot.

De igual forma que en los puntos anteriores, es posible emplear las capacidades del lenguaje C y de un ambiente integrado de desarrollo (DE) para proveer de las funciones de edición que realizan los comandos en modo monitor. Como ejemplos de IDES se tiene al Borlan C/C++ ver. 5, MS Visual C++ ver. 5, Turbo C/C++ ver. 3.1, Builder C++ ver. 3, etc.

5.10 Conclusiones

En este capítulo se presenta de manera resumida los comandos que son comunes en varios lenguajes industriales de programación de robots, a partir de los cuales se proponen un conjunto de funciones que deben estar incluidas en la interfaz de control para permitir que los módulos clientes (propuestos en la seccion 3.9) tengan acceso a los comados manejados por los dispositivos controladores.

Las funciones propuestas se enfocan en cubrir principalmente llamadas a comandos de movimiento y posicionamiento que los controladores industriales ofrecen para el manejo de los robots articulados.

La arquitectura definida en esta tesis propone utilizar esta interfaz de control junto con la interfaz de visión (definida en el capitulo 4) para integrar dentro de un módulo cliente la información requerida para realizar control mediante visión artificial en un robot articulado.

.

74

CAPÍTULO 6

. - - ~- . ~ .

~ MECANISMOS DE INTEGRACI~N

6 Mecanismos de Integración

En este capítulo se presentan las tecnolog s con las cuales puede implementarse las interfaces de comunicación para los servidores de control y de visión, las cuales están especialmente diseñadas para emplearse bajo un esquema cliente - servidor.

El estudio de los mecanismos he integración de sistemas de este trabajo incluye a los sockets de UNIX, los sockets de Windows (WinSock), el Intercambio Dinámico de Datos en Windows, el manejo eventos en Java y las primitivas de comunicación en el sistema operativo de tiempo real QNX.

Este trabajo de tesis, propone que el módulo de control de robot sea un programa escrito en lenguaje C/C++ (el,,cliente dentro de la arquitectura propuesta, véase sección 3.9), y que las interfaces tanto de control como de visión sean incluidas como llamadas a funciones de bibliotecas.

I!

6.1 Integración conceptual

Para integrar la información 'de uno o más sistemas de visión con los sistemas de control se propone un esquema cliente - servidor. Para lograrlo es necesario incorporar capas de software que permita la comunicación entre los distintos sistemas. La propuesta es trabajar de la manera como lo hacen las aplicaciones de Bases de Datos al usar ODBCi(0pen Data Base ConnectiviQ). AI usar ODBC las aplicaciones clientes de bases de datos se sirven de un medio estandarizado para

1

II

I 75

consultar o manipular información desde una fuente de datos (Figura 6.1). Las aplicaciones clientes, al usar ODBC son independientes de la fuente de datos, es decir, la fuente (el servidor de datos) puede cambiarse por otra sin que se tenga que

clientes entre distintas fuentes (servidores) de datos. modificar la aplicación cliente, lo que brinda interoperabilidad de las aplicaciones 'I

Aplicación de Base de Datos

ODBC Cliente

Datos

Servidor de Base de Datos

ODBC Servidor

Comunicación local o remota

Fig. 6.1 Comunicación usando ODBC

Adaptando la idea de ODBC dentro de las aplicaciones, programas y algoritmos de control de robots, podrán obtener la información que necesiten desde alguna fuente de datos y de la misma forma podrán manipular los parámetros de control (Figura 6.2).

Sistema de visión

Interfaz de visión Comunicación l a d o remota

Interfaz de visión

Aplicación de Control

Interfaz de control

Interfaz de Control

Sistema de Control Comunicación I d o remota

4 Parámetros de control

Fig. 6.2 Integraswn Conceptual de visión al control de robots

'!

De tal forma, dentro del esquema de integración se tendrá una biblioteca de funciones (interfaz de visión) para solicitar información visual al servidor de visión, y otra biblioteca de funciones (interfaz de control) para transferir al servidor de

76

control parámetros y comandos de movimiento del robot, como se ilustra en el siguiente pseudocódigo:

>:

I Pseudocódigo para un programa cliente (módulo de control) que realiza llamadas a los servidores de control y de visión

para realiqzr una tarea tipica de <pick and place? , :il

1

2

3 Establecer comunicación con el servidor de visión. 4 Establecer comunicación con el servidor de control. 5 Declarar las variables y los objetos contemplados para la tarea. 6 Iniciar ciclo de control de la tarea 6.1 Solicitar al servidor de visión las coordenadas de localización y

la orientación de un objeto de interés. 6 . 2 Solicitar al servidor de control el ajuste en la posición de la

pinza del robot de acuerdo a las coordenadas obtenidas 6 . 3 Solicitar al servidor de control la operación de cerrar la pinza

para sujetar el objeto. 6 . 4 Solicitar al servidor de visión la confirmación de las

coordenadas del objeto. 6 . 5 Solicitar al serviddr de control trasladar la pinza del robot a

un punto de deposit0,predefinido. 6.6 Solicitar al servidor de visión la confirmación de las nuevas

coordenadas de 1oca;ización del objeto. 7 Terminar ciclo de control de la tarea. 8 Cerrar comunicación con el servidor de control. 9

Habilitar la biblioteca de funciones para la comunicación con el servidor de visión. Habilitar la biblioteca de funciones para la comunicación con el servidor de control.,

Cerrar comunicación con el servidor de visión.

1

De esta manera, un programa' como el anterior (el módulo cliente dentro de la arquitectura cliente - servidor propuesta) permite integrar, por medio de las interfaces, la información de dos aplicaciones totalmente independientes, como son el sistema de visión artificial y el sistema de control del robot. A continuación se presentan algunos mecanismos con los cuales es posible establecer la comunicación entre sistemas distintos y lograr su integración.

77

6.2 Cliente - Servidor en UNIX

U N E es un sistema operativo que goza de gran popularidad en los entornos industriales y universitarios. Su implantación en máquinas con gran capacidad de procesamiento gráfico y de cálculo es muy común. UNIX brinda al programador un conjunto de Zhmadm al sistema, que permiten explotar al máximo los recursos del sistema operativo [MÁRQUEZ1993], tales como usar el sistema de archivos, ejecutar vanos procesos en paralelo o de manera concurrente, implementar algunos aspectos de la programación en tiempo real, recuperarse ante condiciones de error y tolerar fallos imprevistos, comunicarse con otros programas a través de una red local, etc.

El modelo cliente - servidor es el modelo estándar de ejecución de aplicaciones en red. Un servidor es un proceso que se está ejecutando en un nodo (procesador conectado a la red) y que gestiona el acceso a un determinado recurso. Un cliente es un proceso que se ejecuta en el mismo o en diferente nodo, que realiza peticiones de servicio al servidor debido a la necesidad de acceder a los recursos gestionados por el servidor.

La forma genérica que tienen los diagramas de ílujo de control en el modelo cliente - servidor se aprecia en la figura 6.1.

Proceso servidor Proceso cliente -

Abrir el canal de Abrir el canal de comunicación comunicación + +

Comunicar a la red dirección del canal

Conectar con la dirección del servidor

Pedir servicio

Atender al Fin del proceso cliente cliente + Fin del

proceso hijo

'I

Figura 6.1. Estruciura de los p r o p m a s cüente y servidor.

. _ - - . - I!

I

a2eptO Aceptar una conexión.

que se reciba una petición B I ~ U - el proceso hasta

I

r Z v 0 Lecturadelapeticiónde

-

SeNiCiO

En la figura 6.2 pueden verse las llamadas al sistema y la secuencia en que se realiza la conexión entre un servidor y un cliente.

~ Conexión establecida connect() 4 b Petición de conexión

I 1 1 Solicitnd del cliente send()

4 , ,j ~ Petición de servicio

I

Proceso servidor I

Publicidad de la diección

Disposición para aceptar

Respuesta del servidor Envío de los datos al I -b

cliente I!

Proceso cliente

recv() Lectura de la respuesta

del servidor

Apertura del canal

* Procesamiento de

Figum 6.2. Secuencia de llamadas para la conexión mediante sockets \

Un socket representa un punto final de una comunicación. Un socket proporciona un mecanismo para enviar y recibir datos. Los sockets representan una interfaz de

79

comunicación a nivel de la capa de transporte del modelo de red OS1 (Open System Interconection) y es muy común que utilicen el protocolo TCP/IP.

A continuación se presentan en la tabla 6.1 una síntesis de las llamadas al sistema que intervienen en los programas servidores y clientes que se comunican mediante sockets en el sistema operativo UNM (versión propuesta por la Berkeley Sofnvare Distribution).

Tabla 6.1. Funciones básicas para comunicación mediante sockets de UNIX

El apéndice A contiene la codificación en lenguaje C de un programa cliente y un programa senidor, los cuales se comunican entre sí emplendo sockets de UNM. Como se verá más adelante en la sección 6.3, es posible lograr la comunicación de estos p r o g r a m en UNIX también con programas desarrollados bajo el entorno de Windows.

6.3 Cliente - Servidor en Windows

La API de WinSock (Windows Sockets) se basa en la versión BSD (Berkeley Software Distribution) de los sockets, pero también proporciona extensiones específicas para Windows. WinSock es UM parte de la Arquitectura de Sistemas Abiertos de Windows (WOSA), que especifica interfaces con las que se puede desarrollar aplicaciones cliente - servidor [BENNET1997].

Un socket representa ya sea un punto emisor o receptor de una comunicación. Un socket proporciona un mecanismo para enviar y recibir datos.

Para asegurar que los datos que se envían llegarán a su destino en orden, se utilizan sokets de flujo de datos (socket stream). Estos son un tipo de sockets que proporcionan un transporte basado en una conexión confiable. Para las implementaciones TCP/IP de WinSock, los sockets de flujo utilizan el TCP (Protocolo de Control de Transmisión). Los sockets de flujo son Útiles en situaciones en que está enviando grandes cantidades de datos o cuando desea asegurarse de que todos los datos llegan en orden y sin dupücacioues. Además, los programas serán notificadas si se cierra la conexión.

80

Muchas funciones que se utilizan en la API de WinSock son idénticas a la implementación de los sockets de Berkeley de UNM. Sin embargo, hay algunas diferencias como el hecho delque la API de WinSock tiene que ser inicializada antes de poder utilizarse.

Para utilizar los sockets de flujo, primero se debe establecer la conexión y después leer los datos del flujo. El usoa general se muestra en la figura 63.

I

Función de la API de WinSock WSAStartnp (versión, estructura WSADATA) Socket (formato de direcciones, tipo de socket,

Cliente

Descripción inicialización de WinSock Creación de un socket

, H

i II

Servidor Socket vigía Socket de atención

~~

Accept (socket, struct direcciones, longitud struct) Connect (socket, dirección, puerto) Send (socket, datos, longitud, bandera enrutadento) Recv (socket, datos, longitud, bandera ,cola de entrada )

Socket() 1 Socket() Bind() ! Bind()

Listen0 b Accept() (crea socket de conexión)

Connect() 1

Send() I + Recv() Recv() 4 Send0

Closesocket() 1 Closesocket0 Closesocket()

Aceptación de conexiones a un socket Solicita una conexión a un socket Envío de datos a través de un socket Recepción de datos a través de un socket

1 Figura 6.3.Esquema de uso general de los sockets de flujo. I(.

A continuación se muestra en ia tabla 6.2 una síntesis de las funciones principales de la API de WinSock

protocolo) 1 I Bind (soket, &rnct direcciones, longitud sbuct) Listen (socket, número de conexion& aceptadas)

I Asignación de dirección de puerto a un socket I inicia la escucha de conexiones a un socket

I Closesocket (socket) I Cierra un socket I 1

Tabla ó.Z.Princ@ales funciones para comunicación mediante WinSock.

El apéndice B del actual trabajo de tesis incluye la codificación de un programa cliente implementado con la API de WinSock, el cual entabla comunicación con el programa servidor codificado para el entorno de UNIX presentado en el apéndice A. I1

81

6.4 Intercambio Dinámico de Datos en Windows

En el entorno de Microsoft Windows es posible compartir información entre aplicaciones de manera dinámica creando un Enlace de Intercambio Dinámico de Datos @DE Link) entre dos aplicaciones. El DDE es un protocolo para el intercambio de datos entre aplicaciones Windows [PROTER19941.

Un enlace DDE es un canal de comunicación a través del cual la información es transferida de una aplicación a otra. La información puede ser actualizada automáticamente en la aplicación receptora (el cliente) siempre que la información cambie en la aplicación de origen (el servidor). Un servidor DDE puede proporcionar datos a varios clientes DDE, y un cliente DDE puede obtener datos de varios servidores DDE o proporcionar datos a varios servidores DDE. Una aplicación Windows puede ser un cliente DDE, un servidor DDE o ambos a la vez [PETZOLD1996].

Los enlaces DDE usan cuatro operaciones básicas :

1. Request: el cliente solicita al servidor que le proporcione datos o instrucciones. El servidor regresa la información solicitada y el cliente la recibe.

2. Poke: el cliente envía datos o instrucciones al servidor, provocando cambios. 3. Advise: el cliente solicita al servidor que le notifique tan pronto como ocurra

un cambio en un dato especifico. 4. Execute. El cliente solicita al servidor que ejecute una orden o comando.

Cada conversación DDE debe especificar un comando de enlace, una aplicación, un tema, y un elemento. Un enlace también puede especificar el intercambio de datos. Si el dato será intercambiado, entonces el enlace debe especificar el formato del portapapeles (clipboard)’o, distinto al formato de texto.

a) Comando de enlace (Link Command): la operación del cliente que inicia el enlace.

b) Aplicación (Application): el nombre del servidor para el enlace DDE. c) Tema (Topic): el tipo de instrucciones enviadas o datos solicitados en el

enlace. d) Elemento (Item): es el nombre o categoría especifica al tema. Por ejemplo,

bajo en tema de “Variables” un elemento es al nombre de una variable que se este considerando.

lo El clipboard o portapapeles es un mecanismo proporcionado por Windows que permite la transferencia de datos entre aplicaciones. Una aplicación (la fuente del dato) puede colocar datos en el portapapeles, y otra aplicación (el consumidor del dato) puede obtener los datos desde ahí.

82

e) del Portapajpeles (clipboard format): típicamente, 10s datos son intercambiados usando el formato de texto (CF-TEXT), el cual esta estructurado en un formato delimitado por comas (CDF). Para utilizar otro formato distinto, el cliente debe registrar el mismo formato que el servidor.

iI Una vez que se ha establecido una conversación DDE, un cliente DDE puede hacer uso de los siguientes servicios:

I

Terminar la conversación. Pedir algunos datos y esperar la respuesta. Enviar al servidor unos datos no solicitados. Enviar al servidor una orden. Pedir al servidor que actualice unos datos cada vez que éstos cambien.

Los primeros cuatro servicios se pueden manejar de forma síncrona, enviando la petición y esperando una respúesta. El último servicio es un enlace que trabaja de manera asíncrona, el cliente no sabe cuando llegarán los datos, por lo que el cliente no se bloquea en espera de ellos, sino que responde al recibir la notificación de cambio por parte del servidor!

Los enlaces pueden ser calie&es (hot) o tibios (warm). En un enlace caliente, el servidor envía los datos cada vez que los tiene disponibles o cada que cambien, de manera inmediata. En un enlace tibio, el servidor simplemente avisa al cliente que han cambiado los datos pero no los envía, el cliente debe encargarse de pedir los datos actualizados.

El apéndice C de esta tesis contiene la codificación en C++ Builder de un programa cliente y un programa servidor que se comunican empleando la tecnología DDE.

I

1

1

I

6.5 Manejo de Eventos, en Java

Java es un lenguaje de programación orientado a objetos con la característica de ser independiente de la plataforma (hardware) y del sistema operativo en el cual se ejecuta. Los eventos en Java son parte del Abstrac Windowing Toolkit (AWT).

Un evento es un medio a través del cual AWT comunica que algo ha sucedido, como cambios en el medio ambiente del sistema (abrir, cerrar o desplazar una ventana, movimientos y clics del ratón, pulsaciones de teclas, etc.). AI darse cuenta de estos eventos su programa puede reaccionar ante una entrada de un usuario y cambiar su comportamiento dependiendo de esa entrada [LEMAY1988]. En Java los eventos son instancias de una clase particular de eventos.

En Java existen el modelo de eventos de la versión 1.02 y el de la versión 1.1 (véase figura 6.4), los cuales permiten' interceptar un conjunto de eventos en los que esté interesado. El modelo 1.02 utilih un administrador de eventos handleEvent(). El

JI

I

I 83

modelo 1.1 tiene un concepto de auditor de eventos, donde se registran diferentes auditores que son responsables de manejar un conjunto específico de eventos.

Programa

HandleEventO

1 1 1 4 MouseDownO I KeyDownO

Evento (clic)

I

Modelo de eventos Java ver. 1.02

+ (envío)

Modelo de eventos Evento Java ver. 1.1

ventana -

InitO ... inicializar el programa

Modelo de eventos Java ver. 1.1 Programa

Evento

ventana InitO ... inicializar el programa ... registro del auditor del ratón ... inicializar el botón ... registro del botón auditor

o Registro

auditor del ratón

Registro ' auditor de

Figurn 6.4. Comparación entre los modelos de eventos en Java.

El paquete juvu.util contiene una clase publica Observable. Una instancia de esta clase, es decir, un objeto Observable puede tener cualquier número de observadores. Cuando el objeto Observable cambie, notifica a todos sus observadores. Esto signirica que en Java es posible implementar la arquitectura de control propuesta, heredando la clase Observable en los servidores, lo que otorgará a estos la capacidad de comunicar los cambios que perciben a sus clientes (observadores) de manera asíncrona.

Lo que se pretende resaltar es el manejo de eventos en Java y la forma en que facilita la programación basándose en los eventos, esto proporciona al programa la

84

capacidad de responder a los cambios en el entorno y modificar su comportamiento de acuerdo a los eventos que se presenten. Esta capacidad es deseable en los lenguajes de programación de robots. Actualmente no se tiene información acerca de algún lenguaje para robots que incorpore un mecanismo similar para el manejo de eventos. ,)

I

6.6 QNX sistema operativo en tiempo real I

El QNX es un sistema operativo con la característica principal de estar diseñado para soportar el control de procesos en tiempo real [QNX1999]. Una secuencia de sus primitivas de IPC (comunicación entre procesos) send() - receive() -' reply() resultan en la ejecución sincronizada de una operación o en el intercambio de datos entre dos procesos [KüBITZ1998].

Adquisición de un / nuevodato ; * 1

L I

Figura 6.5. Visia cornpacia del modelo de comunicación asincmna.

En algunas implementaciones del modelo cliente - servidor, se requiere un modelo de comunicación m á s desacoplado. Se da el caso cuando el servidor quiere notifcar a un cliente sobre la disponibilidad de nuevos datos o la ocurrencia de ciertos eventos. Cuando el cliente no esta Listo para recibir el mensaje, el servidor puede llegar a quedar bloqueado, y debido a ello otros clientes no podrán ser notüicados a tiempo. AI avisar sobre eventos usando trigger(proxy) se logra desacoplar la comunicación entre los procesos, es decir, la comunicación se vuelve asíncrona (véase figura 6.5). I

i

! 85

Con un modelo de comunicación asícrona, el evento (proxy) es recibido tan pronto como el receptor (cliente) del evento esté listo y el emisor (servidor) no se bloquea cuando dispara un evento con trigger@roxy). Normalmente, hay una distinción entre los dos papeles para los procesos, el papel de proveedor emite un evento para el papel de consumidor. Un evento es disparado por el proveedor, normalmente seguido de UM inicialización para la comunicación de datos entre el proveedor (servidor) y el consumidor (cliente).

El sistema operativo QNX proporciona mecanismos de comunicación de eventos (proxies) sin bloqueos. Un proxy (apoderado o representante) es disparado usando la primitiva trigger() para avisar ai cliente sobre un evento. El proceso que envía un evento no será bloqueado. Después de recibir un proxy de un proveedor, el consumidor utiliza la secuencia de primitivas IPC send() - receive() - reply() del sistema operativo QNX para obtener el nuevo dato.

6.7 Posibles configuraciones

Después del estudio realizado, resulta factible realizar la implementación de las interfaces propuestas por medio de cualquiera de los mecanismos de integración presentados. Las configuraciones de los sistemas se diversifca si se toman en cuenta las tecnologías presentadas y los equipos disponibles en el Cenidet, pudiendo tener los siguientes ejemplos:

A. Sistemas de visión y de control del robot en estaciones de trabajo (servidores y clientes en UNE, véase figura 6.6).

Estación de trabajo

Sistema de Visión I SUSAN I ~~ I ServidordeVisión I

Sockets

SO UNM Solaris

JavaBots

Sockets I Estación de trabajo I

Proceso Cliente I LenguajeCIJava 1 Figura 6.6 Clientes y servidores en UNIX

86

El sistema SUSAN permite identificar la posición de esquinas en imágenes [OXFORD]. Los JavaBots permiten simular sistemas de control multi-robot [GEORGIA]. 1

l

DDE PCcon SO Windows

WinSock I

I-

B. Sistema de visión en estación de trabajo (servidor de visión en U N E ) y sistema de control del robot en PC (servidor de control y cliente en Windows, véase figura 6.7).

I

- I

SO Windows

ROBCOMM

Proceso Cliente - C+t Builder

I InterfazdeControl I

Sistema de lnterfaz ínterfaz visión de D Cliente D de

visión integrador control M A Q C++ Senido DiAS D eVision Servido

visilón control Vision Blox r d e E Buüder E r d e

Sistema de control

Robcomm o Visuaiizador paraelrobot

CRS T476

Figura 6.8 Servidores y cliente en una PC con Windows.

87

Los sistemas IMAQ [NATINS], DIAS [JENA], evision [EURESYS], y Vision Blox [WTEGRALVISION] son herramientas comerciales que facilitan el desarrollo de aplicaciones de visión basadas en PC. El modulo Visualizer p e d t e simular el accionar real de un robot CRS modelo T476 [CRS3].

D. Sistema de visión, sistema de control y cliente en distintas computadoras con sistema operativo Windows, los servidores y clientes comunicándose por medio de WinSock o DDE (véase figura 6.9).

Procesador

t DDE WinSock 1

I ROBCOMM I

T I Programacliente 4 I

C++ Builder

Figura 6.9 Clientes y servidores en distintas PCs con Windows.

Esta configuración permitiría aprovechar las ventajas del computo distribuido, además de facilitar obviamente el desarrollo de un control distribuido.

6.8 Conclusiones

En este capítulo se ha mostrado propuestas para el mecanismo de integración. De manera conceptual se hace la analogía del funcionamiento de las aplicaciones de bases de datos que emplean ODBC para obtener datos de distintas fuentes; de la misma manera, es posible que las aplicaciones de control (clientes definidos en la section 3.9) obtengan datos de distintos sistemas de visión (incluso de otros tipos de sensores) y que puedan usar las funciones típicas de los lenguajes industriales para controlar tareas y manipular robots articulados.

88

I

Para reforzar la propuesta del esquema planteado en el capítulo 3, se presentaron varios mecanismos de comunicación que pueden ser Út i l e s para desarrollar las interfaces propuestas para lograr la integración de distintos sistemas de visión y de control de robots.

Actualmente, tanto las tarjetas de adquisición de datos como el software de control industrial que incluyen la adquisición de imágenes, traen entre sus prestaciones soporte a protocolos de comunicación tales como TCPnP y DDE, facilitando la integración de sistemas por parte de empresas dedicadas a desarrollar aplicaciones para las industrias. Por lo tanto, las aplicaciones de visión arüficial basadas en PC's cada vez son más comunes dentro de los procesos industriales.

1

1

89

c APÍTULO 7

7 Experimentación

En el capítulo 3 se definió el modelo codceptual de la arquitectura cliente - servidor propuesto en esta tesis, así como los criterios para su evaluación, buscando incluir características tales como la modularidad, la reusabilidad, la portabilidad y la abstracción en el manejo de datos, así como facilidades para realizar pruebas y para dar mantenimiento a los sistemas.

En este capítulo se presenta el plan de pruebas usado para experimentar con el prototipo desarrollado con el obejtivo de evaluar la facilidad para integrar la información generada por un sistema de Visión hacia el sistema de control Robcomm, el cual interachía con el controlador CSOO del robot articulado CRS T476.

7.1 Plan de pruebas

La estrategia para comprobar la arquitectura cliente - servidor es análoga a la estrategia de comprobación para sistemas basados en software, donde las pruebas de unidad y de integración se centran en la verificación funcional de cada módulo y en la incorporación de esos módulos en una estructura de sistema superior [PRESSMAN1998].

La comprobación comienza al por menor, es decir, se comprueba una única aplicación de cliente. La integración de los clientes con los servidores se irá comprobando progresivamente. Finalmente, se comprueba todo el sistema como unidad operativa.

90

El plan de prueba propuesto ha sido adaptado del plan de comprobación cliente - servidor [PRESSMAN1998]1sugerido por el GurtnerGroup” :

1 Comprobación de las interfaces 1.1

1.2

1.3

1.4

Identificación de escenarios de tareas: La tarea será un programa típico de pick and place. Creación de casos de prueba: Localización de varios objetos de la misma clase, con base en un patrón previamente aprendido por el sistema de visión. Verificación: Se verifcará que la información generada por el sistema de visión fluya hacia el sistema de control. Herramientas de comprobación: Se hará un monitorm de la información transmitida a través del protocolo DDE (Intercambio Dinámico de Datos).

2 Servidor (de visión) 2.1

2.2

2.3

2.4

Creación de datos de prueba: Pruebas de localización de varios objetos de la misma clase, de acuerdo a un patrón previamente aprendido. Comprobación de volúmenes I esfuerzo: Se tomará el tiempo promedio en la identificación de los patrones. Verificación: Se verificará el grado de confianza en la identificación de patrones. Herramientas de prueba: Sistema de visión eVision, sistema operativo Windows, PC con procesador Pentium MMX, cámara y tarjeta de adquisición de imágenes.

3 Conectividad 3.1

3.2

3 3

3.4

Rendimiento: Se medirá el rendimiento en la transmisión de datos cliente - servidor al usar el protocolo DDE. Comprobación de volúmenes I esfuerzo: Se probaran varios clientes conectados a un solo servidor. Verificación: Se medirá el desempeño de la capacidad de la tecnología DDE con varios clientes conectados simultaneamente a un solo servidor. Herramientas de prueba: Programa servidor DDE y programas cliente DDE en sistema operativo Windows 98.

4 4.1

4.2

4.3

4.4

Calidad técnica del mecanismo de integración Definiciones: Facilidad para implementar la integración de los programas clientes DDE con los programas servidores DDE Identificación de defectos: Identificar las limitantes, así como los defectos y restricciones en el protocolo y programas usados. Métricas: Se pretende evaluar el nivel de modularidad de acuerdo a la arquitectura cliente - servidor propuesta. Calidad del código: Establecer la facilidad para integrar los módulos clientes y servidores.

” El GartnerGroup es una asociación internacional de consultores en tecnología de la información.

91

4.5 Herramientas de prueba: C++ Bniider, Sistema operativo Windows 98, Programas Cliente DDE y Servidor DDE.

5 5.1 5.2 5.3 5.4

Comprobación funcional del robot articulado CRS modelo T476 Definiciones: Programación de la tarea de ‘pick and place’. Creación de datos de prueba: Definición de las variables de localización. Verificación : Validación de la realización de la tarea programada. Herramientas de prueba: Programa Robcomm, lenguaje RALPII, controlador C500, robot articulado CRS modelo T476.

6 6.1 6.2 6.3 6.4

Comprobación de sistemas en la integración del protoüpo Definiciones: Entradas y salidas de cada componente del prototipo. Comprobación operacional: Funcionamiento de la operación del prototipo. Verificación: Estimación del tiempo empleado para la realización de la tarea. Herramientas de prueba: Programa Robcomm, lenguaje RALP 11, controlador C500, robot articulado CRS modelo T476, cliente DDE, servidor DDE, sistema de visión eVision, Windows 98, PC con procesador Pentium MMX.

La descripción del prototipo, las herramientas y los resultados experimentales se describen en la siguiente sección.

7.2 Resultados experimentales

En esta sección se desarrolla el plan de prueba citado en el punto 7.1 con la fmalidad de mostrar la funcionalidad de la arquitectura cliente - servidor propuesta como solución (véase capítulo 3), la cual fue definida dentro de este trabajo de tesis buscando un esquema para integrar la información visual al control de un robot. Se presentan los resultados observados en el prototipo que se desarrollo de acuerdo al esquema definido para la integración de sistemas de visión al control de robots, así como las consideraciones sobre la tecnología DDE (definida en el punto 6.4) empleada como mecanismo de integración, además de las observaciones y conclusiones que se proyectan para dar continuidad a este trabajo de desarrollo tecnológico especifico al grupo de visión artificial del Cenidet.

7.2.1 Comprobación de las interfaces Para probar el prototipo diseñado bajo el esquema propuesto en esta tesis, se realizará un ejercicio depiek andplace (véase apéndice D) con el robot CRS T476.

7.2.1.1 Identificación de escenarios de tareas Las tareas denominadas como pick and place, consisten en recoger los objetos y colocarlos en un contenedor o punto de depósito, por io tanto, es necesario identificar los valores de las coordenadas y orientaciones de los objetos (piezas o

92

Variable de Localización

A1 A2 A3

93

X Y Z Tiempo para actualización

13 12 10 7 segundos 13 -12 12 4 segundos 11 22 33 6 segundos

Se registraron los siguientes resultados durante las pruebas de reconocimiento, realizadas sobre tres imágenes de prueba con ángulos de O, 10 y -10 grados de inclinación respectivamente:

Aprendizaje del patrón 6.839 milisegundos Imagen 1 (ángulo O")

1 objeto a localizar 2 objetos a localizar 3 objetos a localizar 4 objetos a localizar 5 objetos a localizar 6 objetos a l o c a l i r

Imagen 2 (ángulo máximo Io") 1 objeto a localizar 2 objetos a localizar 3 objetos a localizar 4 objetos a localizar 5 objetos a localizar 6 objetos a localizar

Imagen 3 (ángulo mínimo -10") 1 objeto a localizar 2 objetos a localizar 3 objetos a localizar 4 objetos a localizar 5 objetos a localizar 6 objetos a localizar

132 milisegundos 109 115 129 140 149

142 milisegundos 149 178 210 249 283

164 milisegundos 278 363 394 430 474

Grado de confianza

0.9928 0.9954 0.9966 0.9974 0.9951 0.9904

0.9096 0.9001 0.9016 0.9056 0.9044 0.9065

0.9935 0.9858 0.9815 0.9826 0.9808 0.9889

TabIn 7.2: Reconocimiento de objetos sobre In herramienta Easy Match del software eVision.

Se deben considerar estos tiempos de respuesta por parte del servidor de visión para acumularlos dentro del tiempo de respuesta total del prototipo y tenerlos en cuenta para la posible realización de otro tipo de tareas.

Herramientas de prueba Procesador Pentium MMX con 16 MB en RAM Sistema operativo Windows 98 Herramienta Easy Match de eVision Imagen patrón Imágenes de prueba

7.2.23 Conectividad Se realizó una prueba para conocer el rendimiento de la tecnología DDE (definida en la sección 6.4) respecto al número de clientes que soporta un servidor, se registró el tiempo requerido para atender a los clientes por parte del servidor DDE (véase siguiente tabla).

94

7.2.2.4 Comprobación de volúmeneslesfueno Se realizó la prueba de conectividad hasta con 5 clientes DDE conectados a un solo servidor DDE. Cada cliente recibió desde el servidor 4 padmetros de manera constante.

A continuación se presentan los resultados observados en el rendimiento de la conectividad con la tecnología DDE, registrando los siguientes tiempos para la actualización de los datos entre el servidor y los clientes:

Volumen Esfuerzo (tiempo requerido por el servidor DDE)

6 milisegundos 8 milisegundos 10 milisegundos 12 milisegundos 14 milisegundos

Tabla 7.3: Desempeño del protocolo DDE con varios clientes simu[táneos.

Herramientas de prueba Procesador Pentium MMX con 32 MB en RAM Sistema operativo Windows 98 Programa cliente y servidor DDE (incluidos en el apéndice C)

7.2.3 Calidad técnica Para apreciar la calidad técnica del mecanismo de integración se realizó un análisis de los programas cliente y servidor DDE del prototipo, incluidos en el apéndice C.

7.2.3.1 Calidad del código El código escrito en C++ para los programas cliente y servidor resultan ser compacto y legible, facilitando el desarrollo rápido de programas que intercambien información de manera dinámica y orientada a eventos.

Característica Cliente DDE Servidor DDE Líneas de código Módulos Llamadas a métodos

Tabla7.4:Análisis del código de los programas cliente y servidor.

7.2.3.2 Identificación de defectos En esta sección se aprovecha para comentar las limitantes del prototipo. El prototipo desarrollado es semiautomático. Los datos generados por el servidor de visión (eVision) deben ser proporcionados manualmente al cliente DDE (módulo integrador), el cual envía automáticamente los datos de intercambio al servidor de control (Robcomm).

95

7.2.33 Métricas Se consideró el número de líneas de código contenidas en los programas cliente y servidor DDE (apéndice C), así como el grado de módularidad y el número de llamadas a métodos, procesos o funciones (véase tabla en la siguiente sección).

Herramienías de prueba Los programas cliente y servidor DDE fueron escritos en lenguaje C++ usando el ambiente de desarrollo de C++ Builder de Borland [BORLAND], el cual ofrece componentes que permiten establecer la comunicación entre aplicaciones Windows por medio del protocolo DDE.

7.2.4 Comprobación funcional La programación del robot articulado CRS modelo T476 es por medio del RAPL I1 [CRS3], el cual es un lenguaje estructurado basado en comandos usado para programar aplicaciones con robots. La tarea programada es un ejemplo típico de pick and place.

7.2.4.1 Creación de datos de prueba Para probar la funcionalidad del prototipo se requiere declarar algunas variables de localización dentro del programa del robot, basadas en coordenadas cartesianas.

El listado del programa y las variables de localización definidas para la ejecución de la tarea de pick and place se anexa en el apéndice D. Se utilizó el lenguaje de programación RAPL 11 y el editor de variables de localización del software Robcomm.

7.2.4.2 VeriFcación Durante la ejecución de la tarea se verifican los valores de las variables de localización definidas en el programa del robot. Lo importante es notar el hecho que dentro del programa, las variables de localización son estáticas. Se pretende, mediante el uso del módulo integrador (cliente DDE), hacer que las variables de localización y demás variables en general dentro del programa, sean manipuladas de manera dinámica.

Herramientas de prueba Procesador Pentium MMX con 32 MB de RAM Sistema operativo Windows 98 Software Robcomm Lenguaje de programación para robots RAPL Ii Controlador C500 Robot articulado CRS modelo T476 Programa para ejecutar tarea depick andplace

96

7.2.5 Comprobación del prototipo El prototipo desarrollado para mostrar la funcionalidad del esquema propuesto se integra con los siguientes componentes (véase figura 8.1): la herramienta eVision como servidor de visión, el software Robcomm como servidor de control y el programa cliente DDE como módulo integrador.

b) Servidor de visión Aümentación a manual de las

coordenadasde localización ..........................................................................

. de a) Servidor control

I

e) Módulo integrador

Intercambio dinámico de datos

*: “X . .* ..~ , .. *”#. I. -. . ”,,_ ..P (actualización

Figuro 8.1. Prototipo basado en el esquema propuesto cliente - servidor

7.2.5.1 Comprobación operacional La operación del prototipo (fig. 8.1) se comprueba de la siguiente forma:

a) 1.

2.

3.

4.

5.

Servidor de control En la opción DDE del menú Setup del software Robcomm se introduce un nombre de servidor que permita al cliente identificarlo para la comunicación DDE. Se define en milisegundos cada que tiempo el servidor noafcará al cliente de los cambios en los datos. Se deshabilita el modo emulador terminal seleccionando la opción Lock out terminal mode, debido a que el modo emulador terminal interrumpe las comunicaciones de acceso al controlador del robot. Se activa la opción Save settings on exit del menú Setup y se reinicia el software Robcomm para activar la nueva configuración. Se selecciona la opción Lock en la caja de diálogo DDE del menú Setup para asegurar que el Robcomm no se cierre hasta que el cliente termine y libere el enlace DDE.

91

b) Servidor de visión 1. La herramienta Easy Match de eVision se entrena con una imagen patrón para

realizar el reconocimiento. 2. Se cargan las imágenes de prueba con los objetos a reconocer. 3. Se define el número de objetos a localizar y se ejecuta el reconocimiento. 4. La hoja de resultados de Easy Match presenta las coordenadas y los ángulos de

los objetos localizados en las imágenes de prueba.

c) Módulo cliente integrador 1. Las coordenadas de los objetos localizados por la herramienta Easy Match se

introducen manualmente en el programa cliente DDE. 2. Los datos son enviados automáticamente hacia el servidor de control mediante

intercambio dinámico de datos @DE). 3. Las variables de localización dentro del programa del robot son actualizadas

automáticamente sin interrumpir el ciclo de ejecución de la tarea.

Herramientas de prueba Procesador Pentium MMX

Sistema operativo Windows 98 Herramienta eVision como servidor de visión

Imagen patrón Imágenes de prueba

Programa depick andplace en lenguaje RAPL I1 Controlador C500 Robot articulado CRS modelo T476

Programa Cliente DDE C++ Builder de Borland

Software Robcomm como servidor de control

Módulo integrador

7.2.5.2 Casos de Prueba Para los casos de prueba se emplean los programas de ‘<pick and place” y “Cliente - Servidor DDE” anexados en los apéndices D y C, respectivamente. Se definieron tres casos de prueba para mostrar la integración entre el sistema servidor de Robcomm y el módulo Cliente DDE. El programa Robcomm es el servidor que da acceso al dispositivo de control G O O , encargado de almacenar los programas y las variables de localización que definen las coordenadas de movimiento del brazo articulado T476. El programa Cliente DDE se encarga de establecer el enlace de comunicación y pasar los nuevos valores para las variables de localización de manera dinámica.

Los casos de prueba son los siguientes: 1) Ajuste a una variables de localización 2) Ajuste a dos variables de localización 3) Ajuste a tres variables de localization

98

Verificación Se verificó que los valores de las variables de localización fueran automáticamente actualizadas al observar que el programa del robot responde a los nuevos valores de localización sin interrumpir la ejecución de la tarea del programa de pick and place.

7.3 Conclusiones

En este capítulo se plantea la problemática sobre evaluación de arquitecturas y la importancia de definir los criterios de aceptación que deben cumplir los sistemas desde su diseño y fase de pruebas. Los sistemas deben construirse preferentemente con base en arquitecturas bien definidas, arquitecturas que cumplan con ciertos principios de diseño y de estructura, buscando dar un balance entre capacidad, compromiso, complejidad e incertidumbre.

Para efectos de evaluación de la arquitectura propuesta para integrar visión artificial al control de robots articulados, se planteo que la arquitectura debería de buscar un balance entre la abstracción de los sistemas para facilitar el acceso a su información, facilitar la integración de módulos con cierto grado de independencia, y así mismo, favorecer la comunicación entre los distintos subsistemas o módulos.

El plan adoptado para evaluar la arquitectura propuesta, así como el prototipo, esta basado en el plan de pruebas propuesto por el Gartner Group [PRESSMAN1998], plan que esta orientado a probar sistemas de tipo cliente - servidor. Se considera que una de las partes más importantes en este desarrollo es mostrar la facilidad para crear prototipos dentro del esquema propuesto. La arquitectura al estar basada en el modelo cliente - servidor esta orientada a lograr la comunicación de una manera abstracta entre los módulos y subsistemas de visión artificial y de control de robots articulados. El incluir un mecanismo para manejo de eventos permite al subsistema de control atender y reaccionar rápidamente ante las solicitudes de información y posibles cambios en el entorno percibido por el subsistema de visión artificial.

99

CAPÍTULO 8

CONCLUSIONES

8 Conclusiones

Este trabajo de tesis ha sido desarrollado con la finalidad de definir un esquema que permita integrar los sistemas de Visión artificial al control de robots articulados buscando un diseño modular, reutilizable e interoperable.

Dentro del estado del arte se estudió la arquitectura tradicional, limitadas en su capacidad de adaptación y respuesta, se presentó a la arquitectura reactiva que funciona con mecanismos de inhibición y supresión de conductas priorizadas, se encontró a la arquitectura neuro-etológica basada en mecanismos de redes neuronales que asocian los estímulos sensoriales con ciertas reacciones programadas o aprendidas. También se estudió una arquitectura basada en agentes que colaboran planificando acciones para lograr directivas de movimiento según metas programadas. Ninguno de estos esquemas propone un acceso abstracto a la información de los sensores, es decir independencia del dispositivo hardware, ni plantean un manejo modular de los dispositivos, sino que se centran en un ciclo de entrada - planeación - salida, tampoco ofrecen un esquema donde los componentes de software puedan ser utilizadas para distintas tareas y entomos, ni de manera independiente a los dispositivos físicos.

Por otro lado, se estudio una arquitectura modular que propone el desarrollo de operaciones de control sencillas, a manera de primitivas de control, que se combinan para lograr operaciones más complejas, con la idea de poder aplicar tales módulos en la realización de diversas tareas de posicionamiento y control de robots articulados.

Sin embargo, la alternativa que más se apego a los objetivos planteados de un diseño con módulos reutilizables e interoperables fue la arquitectura basada en el modelo cliente - servidor. El enfoque cliente - servidor se adapto para permitir al diseñador de sistemas de control de robots modelar los sistemas de visión artificial y los sistemas de control de robots articulados como módulos servidores que cuenten con interfaces abstractas facilitando la comunicación con módulos clientes que contengan los algoritmos de control de la tarea que se pretenda realizar. Dentro del

100

esquema cliente - servidor se propone la incorporación de un mecanismo de manejo de eventos que favorezca la capacidad de adaptación y respuesta de todo el sistema.

8.1 Conclusiones El esquema propuesto en este trabajo de tesis proporciona una guía para el desarrollo de prototipos que integren la visión artificial (y opcionalmente otro tipo de sensores) dentro del control en los programas de robots, de una manera rápida y modular, donde los componentes conservan independencia entres sí, pudiendo conjuntarse, así como remplazarse, para la ejecución de distintas tareas, dentro de sistemas más complejos o más específicos.

Se cubrieron los siguientes objetivos planteados al inicio del proyecto de tesis:

a) Se definió un esquema de integración, basado en la arquitectura cliente - servidor, y se definió un conjunto de interfaces que permita integrar de forma abstracta la información visual al control de robots articulados.

b) Se desarrollo un prototipo de prueba para mostrar la funcionalidad del esquema propuesto, mostrando que puede ser útil en el diseño de sistemas que integran visión y control, facilitando el desarrollo rápido de prototipos de sistemas de esta naturaleza.

c) Se confirmó la hipótesis definida al inicio de esta tesis: el diseño para sistemas que integran la visión robótica puede hacerse de manera modular, con independencia de la tarea a realizar y con independencia de los dispositivos fisicos.

Aprovechando los recursos de los mecanismos de comunicación entre procesos se puede lograr que la información que se obtiene de los sistemas de visión artificial se integre en los procesos encargados de ejecutar y controlar las tareas de los robots articulados.

Para la evaluación del esquema se adopto el plan de pruebas propuesto por el Gartner Group para sistemas cliente - servidor, verificando la facilidad para integrar la información generada por los sistemas de visión artifical a los sistemas de control de robots industriales como el CRS T476.

101

8.2 Trabajos futuros

Se pretende que dentro del área de Sistemas Basados en Conocimiento, se de continuidad a este trabajo, para lo cual se proponen las siguientes actividades:

Mejorar el prototipo actual, optimizando la comunicación entre el servidor de visión, el cliente integrador y el servidor de control del robot articulado.

Implementar el conjunto de funciones definidas dentro de las interfaces de visión y control.

Realizar pruebas utilizando distintas herramientas de visión y de ser posible, con otros sistemas de robots, bajo distintas configuraciones como las propuestas en la sección 6.7

Realizar un análisis acerca de los tipos de tareas para los cuales resulta aceptable la arquitectura cliente - servidor propuesta.

Aplicar el esquema de integración en la ejecución de tareas reales de automatización industrial.

102

9 Referencias

[ANGULO19841

tBAXES19941

[BENNET19971

[BORLANDI

[cm11

[cm21

[CRS1994]

[CRS3]

[EURESYS]

[GARCIA19971

[GEIB1994]

[GEORGIA]

[GONZALES19871

[GROOVER1986]

A N G ~ O USAmGUI, José Ma. Y AVILEZ GONZALES, Rafael, Visión de Máquinas, Paraninfo, 1984 ISBN 84-283.1315-6, P. 251

BAXES, Gregory A., “ Digital Image Processing, Principles and Applications ”, Wiley, 1994, ISBN 0-471-00949-0, P. 155

BENNET, David, Visual C++ 5.0 Para Desarrolladores, Prentice Hall Hispanoamericana, México, 1997, ISBN 970-17-0124-0, capítulo 16: WinSock, p.p. 437 - 467.

C++ Builder de Borland, Herramienta para desarrollo de aplicaciones de software. Información disponible como página Web htt~://www .borland.com

ROBCOMM, Documentación del software “Robcomm for Windows ver. 432k”, CRS Robotics Corporation.

Visualizer, Software para simulación, CRS Robotic Corporation, Ayuda en línea.

CRS Robotics Corporation, ‘ ‘ U P II Command Help”, Robcomm for Windows, ver. 4.32,1994

RAPL II, incluido en la documentación del software “Robcomm for Windows ver. 432k”, CRS Robotics Corporation.

evision, Euresys S.A., Industrial Vision System, Disponible como página Web: http://www.euresvs.com

GARCIA CARRISAL, Victor Angel, “interpretación de Dibujos Geométricos Utilizando Visión por Computadora”, (Tesis M.C. Ciencias Computacionales; México: Centro Nacional de Investigación y Desarrollo Tecnológico, 1997) AT 132

GEIB, LEVISON y MOORE, “SodaJack: an Architecture for Agents that Search and Manipulate Objects”, (USA: University of Pennsylvania, Deparhnent of Computer and Information Science) Technical Report, 1994.

JavaBots, Georgia Tech Research Corporation, Información disponible como página Web: http://www.cc.gatech.edd-tucker/JavaBots

GONZALES, WINTZ, “Digital image Processing”, Addison - Wesley, 1987, ISBN 0-201-11026-1 (2‘. edición), p. 30

GROOVER, WEISS, NAGEN, ODREY, “Industrial Robotics, Technology, Programming, and Aplications”, McGraw Hill, 1986,

103

http://borland.com

http://www.euresvs.com

http://www.cc.gatech.edd-tucker/JavaBots

ISBN 0-07-024898-X, p. 117

HAGER, GregOrY D.,”The X-vison system: A generalpurpose subsh.de for real-time vision-based robotics?’, in Prm. Worhbop on vision for Roboh, 1995.4. 56-63. También disponible como Yale cs-rn-1078, Y como página Web en: bm>:~~WW.CS.Yale .EDU:8800 /HTMLIYALE/CS/A~i~ i~~~~bot~~ s/xvision/

HAGER, Gregory D., “A Modular System for Robust Positioning Using Feedback from Stereo Vision”, IEEE Transactions on Robotics and Automation. Vol. 13, No. 4, August 1997, p.p. 582 - 595

HARALICK, SHAPIRO, “Computer and Robot Vision”, Addison - Wesley, 1992, ISBN 0-201-10877-1 (Volumen 1), p. 28 - 48

IGLESIAS ZARATE, José Arturo, “implementación de un Sistema de Visión para la Detección , Reconocimiento y Manipulación de Piezas de Ensamble”, (Tesis M.C. Ciencias Computacionales; México: Centro Nacional de Investigación y Desarrollo Tecnológico, 1991) AT 017

Vision Blox, Integral Vision, Disponible como página Web: http://www.visionblox.com

JAIN, KASTüRi, SCHUNCK, “Machine Vision”, Mc Graw Hill, 1995, ISBN 0-07-032018, p. 13

DIAS, Universidad de Jena, Alemania, “Sistema de procesamiento de imágenes interactivo”Disponib1e como página Web http://pandora.inf.uni-jena.de/pframe.pht~~dia~d¡asl.inc

JIMÉNEZ CRUZ, Joel y ESPINOSA ESPINOSA, Ismael, “Arquitecturas de Control para Robots Móviles”, Smposium Internacional de Computación 1998 (México: Centro de Investigación en Computación) p.p. 361 - 367

JOYANES AGUILAR, Luis, “Programación Orientada a Objetos, Conceptos, Modelado, Diseño y Codificación en C++”, McGraw HüI, 1996, ISBN 84-481-0590-7

KUBITZ, BERGER y STENZEL, “ClientServer-Based Mobile Robot Control”, IEEEIASME Transactions on Mechaíronics. Vol. 3, No. 2, June 1998, p.p. 82-90

LEMAY, Laura, Aprendiendo Java 1.1 en 21 días, 2‘ edición, hentice Hall, 1998, SBN: 970-17-0054-6, pp. 251 - 291

LOUGHEED, SAMSON, “30 Imaging Systems and High - Sped Processing for Robot Control”, Machine Vision and Aplications, 1988, Vol. 1, p. p. 41 - 57. Compilado en : KASTURI, JAIN, “Computer

[HAGER1995]

IHAGER19971

rnRALICK19921

[IGLESIAS19911

[INTEGRALVISION 1

[JAIN1995]

[JOYANES1996]

[KUBITZ1998]

fLEMAY19881

[LOUGHEED19881

104

http://subsh.de

http://www.visionblox.com

tMÁRQUEZ19931

[MEDINA1998]

[NATH1995]

[NATlNS]

[NELSON19961

[OXFORD]

[PARKER19941

FENICHE19981

[PETZOLD1996]

[PRESSMAN19981

PROTER19941

[QNX1999]

Vision, Advances and Aplicatiüns>’, IEEE Computer S’JCieW Ress, 1991, ISBN 0-08186-9103-4, P. P. 631-632

MRQUEZ G A R C ~ , Feo. Manuel, UNM Programación Avanzada,

M E D ~ A BARRERA, Mana Guadalupe, “Metodolo& para el Reconocimiento de Fonemas en el Idioma Español Mediante Percepción Visual por Computadora”, (Tesis M.C. Ciencias Computacionales; México: Centro Nacional de Investigación y Desarrollo Tecnológico, 1998) AT 163

NATH, Aloke, The Gujde to SQL Server, Addison Wesley, 2” Edición, USA, 1995, Beneficios del computo cliente - servidor, p.p. 61 - 63

IMAQ, National instruments, Vision Evaluation Software, Disponible como pagina Web bttD://www.natinst.com/imaq

NELSON, Bradley J., et. al., “Robotic Visual Servoing and Robotic Assembly Tasks”, IEEE Robotics & Automation Magazine, junio 1996, p. 23

SUSAN, Universidad de Oxford, “Method for digitally processing images to determine the position of edges and/or comers therein for guidance of unmanned vehicle”, UK Patente 2272285. Propietario: Secretary of State for Defence. Disponible como página Web: htto://www.fmrib.ox.ac.uk/-steveísusanísusan2k.c

PARKER, J. R., “ Practical Computer Vision Using C ”, Wiley, 1994,

Addison - Wesley RA - MA 1993, ISBN 0-201-64181-X, P* 307

ISBN 0-471-59262-5, p. 68

PENICHE RUIZ, Larissa Jeanette, “Aplicación de Celdas Holográficas sobre Mapas de Detalle para el Reconocimiento de Rostros”, (Tesis M.C. Ciencias Computacionales; México: Centro Nacional de Investigación y Desarrollo Tecnológico, 1998) AT 154

PETZOLD, Charles, Programming Windows 95, Microsoft Press, USA, 1996, ISBN 1-55615-676-6, Capítulo 17: Intercambio Dinámico de Datos @DE), p.p. 871 - 937.

PRESSMAN, Roger, “Ingeniería del Software. Un enfoque práctico”, 4’ edición, 1998, ISBN 0-07-052182-4, Capítulo 28: Ingeniería del software clientelsenidor, pp. 525 - 538

PROTER, Anthony, Programación en C++ para Windows, McGraw Hilt, 1994, ISBN: 84-481-0182-0, Capítulo 11: Intercambio Dinámico de Datos, pp. 363 - 442

QNX Software Systems Ltd., 1999, Disponible cómo Web Site: www.qnx.com

105

http://www.qnx.com

[RECHTiN1991] RECHTIN, Eberhardt, “Systems Architecting, Creating & Building Complex Systems”, Prentice Hall, 1991, ISBN: 0-13-880345-5, p. 144

SMITH, Stephen, “SUSAN version 2k”, Oxford, UK, 1998 Disponible como página W e b hthx/lwww.fmrib.ox.ac.uk/-stevdsusadsusan2k.c

VAUGHN, Larry T., Client/Server System Design & implementation, McGraw Hill, USA, 1994, ISBN 0-07-067375-6, Capítulo 2: Beneficios, Promesas y Obstáculos, p. 13

VELARDE MARTINEZ, Apolinar, “Sistema de Visión Artificial para la Verificación del Llenado de Recipientes no Opacos Utilizando Redes Neuronales Artificiales”, (Tesis M.C. Ciencias Computacionales; México: Centro Nacional de Investigación y Desarrollo Tecnológico, 1998) AT 162

[SMITH19981

IVAUGHN19941

[VELARDE19981

106

10 Apéndice A: Programas Cliente - Servidor.en U N E ~~k apartado contiene el código en lenguaje c de Un programa sXvidor Y un program cliente, 10s cuales se desarrollaron en el entorno de UNE Y emplan llamadas a sockets para comunicarse entre sí. Primero se tiene que ejecutar el programa senidor, una vez que esté listo, pueden ejecutarse y conectarse con éxito hasta 3 programas clientes.

El programa servidor una vez que acepta la socilitud de conexión, recibe cadenas de caracteres, convierte los caracteres a mayusculas y envia la cedena en .mayusculas de regreso al cliente.

/ * Cenidet sistemas basados en conocimiento edson ignacio peralta abundes G9755029

tesis: esquema para la integracion de sistemas de vision robotica

programa servidor üNIX */

#include cstdio.h> #include sstdlib.h> #include <sys/types.h> #include csys/socket.h> #include cnetinet/in.h>

#define MAX-LINE 120

extern int errno;

main ( )

struct sockaddr-in lsock. fsock, sname; int s ; / * identificador socket incompleto * / int s s ; / * identificador socket completo */

int 1.3, i: / * longitud de cadena e indice * / char buf [MAX-LINE1 ; /* buffer cadena de caracteres (datos) * /

/ * se crea un socket de flujo incompleto * / if((S = SOCket(AF-INET, SOCK-STREAM, O)) c o ) (

) ;

{

perror ( "SOCKET : exit L O ) ;

I 1sock.sin-family = AF-INET: / * familia de protocolos * / 1sock.singort = htonsi15000); / * puerto para dar servicio * / 1sock.sin-addr.S-un.S-addr = O; / * direccion IP maquina servidora * /

if (bind(s, (struct sockaddr * ) &lsock, sizeof (struct sockaddr-in) )<O) { perror("B1ND: "1; exit (1) ;

1 / * se habilita para recibir peticiones de servicio,

definiendo una cola de atencion de longitud 3 * /

107

if (listen(s.3) < O ) { / * puede aumentarse el numero de conexiones * / perror ("LISTEN: " ) ; exit(1);

I

printf ("Servidor listo \ w ) ;

while(1) ( / * proceso vigia */ len = sizeof(struct'sockaddr~in1; / * tamano socket esperado * / / * se acepta la conexion con un cliente, se saca la peticion

de la cola creando un nuevo socket completo que atendera la solicitud del cliente * /

if ( ( s s = accept ( s , (struct sockaddr * ) &fsock, Glen)) < O) { , , perror ("ACCEPT: 1 ) ) ;

continue; 1 printf ("Conexion en el socket %d (antes %d) \nor, s s , s ) ;

/* se crea un proceso con la llamada a fork0 para dar atencion a la solicitud del cliente * /

if(fork() == O)( / / se crea un nuevo proceso / * aqui se ejecuta el proceso de atencion al cliente

se dedica a atender la conexion con el socket completo * /

printf ("\n Proceso Servidor de atencion socket: %d \n", cs) ; close(s); / * se cierra el socket incompleto * /

while(1) [ / * atencion a las solicitudes del cliente */

if((1en = recv(ss, buf, MAX-LINE-1. O)) <= O ) { /* si len = O el cliente cerro la conexion */

perror("RECV: " I ; / * recibe datos */ exit (1) ;

} /* servicio: * / / * despliega y transforma a mayusculas */ for(i=o; i<ien; i++) (

putchar(buf [il) ; if(buf[il >= 'a' && buf [il c= '2')

buf [il = 'A' + (buf [il -'a'); 1 putchar ( ' \n' ) ;

/ * condicion de desconexion * / if (buf [ O ] == 'Q' I I buf [O] == 'q') ( printf ("Termina el cliente \n") ; close(ss); / * cierra socket completo */ printf ("\n Proceso servidor terminado socket: 4id". ss) ; exit(0); / * se elimina proceso de atencion * /

/* envia datos * / if (send(ss,buf,len, O ) <len) / * respuesta al cliente */

perror("SEND: " ) ;

) / * fin while interno de atencion a solicitudes*/

) / * fin if fork, termina codigo proceso de atencion*/

/ * aqui continua el proceso vigia para aceptar otra conexion * / else

close(ss); / * el vigia cierra el socket completo que dejo al proceso de atencion * I

108

) / * fin while externo, proceso.vigia*/ } / * fin main programa servidor*/

El programa cliente una vez conectado solicita una cadena de caracteres, la envía al servidor y espera para recibir la respuesta. Un carácter 'Q' al inicio de la cadena enviada sirve para indicar que termina la comunicación con el servidor.

/ * Cenidet

sistemas basados en conocimiento edson ignacio peralta abundes G9755029


programa cliente UNIX * /

#include <stdio.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/time.h> #include <netinet/in.h> #include <sys/errno.h> #include <netdb.h>

#define W-LINE 120

extern int errno;

main (int argc, char *argv [ J )

char buf[W-LINEl; / * cadena de caracteres (datos) * / struct sockaddr-in fsock, sname; struct hostent *hent; / * guarda el llamada a gethostbyname * / int s, len; / * socket y longitud * /

/ * se obteiene la direccion del host donde se ejecuta el servidor */ / * dirección obtenida de la lista de argumentos al programa cliente*/ if ( ! (hent = gethostbyname(argv[ll)) ) {

{

perror ("GETHOSTBYNAME: " ) ; exit ( O ) ;

)

/ * se crea un socket de flojo (stream) con familia de protocolo y direcciones internet * /

if ( ( 8 = socket(AF-INET, SOCK-STREAM, O ) ) c O) { perror("S0CKET: " ) ; exit ( o ) ;

}

fsock.sin-family = AF-INET; / * familia de direcciones * / fsock.sin-addr.s-addr = *(long * ) hent->h-addr; /*IP maquina remota*/ /*puerto maquina remota en formato BIGENDIAN formato de red htons * / fsock.singort = htons(i5000) ;

109

/ * se solicita Conexion con el socket del servidor * / if (connect ( s , (struct sockaddr * ) &fsock,

sizeofistruct sockaddr-in))==-i)[ perror("C0NNEC~: ' 1 ) : . . close ( s ) ; exit (O) ;

1 printf("Arranca programa cliente, oprima 'q' para terminar \nu);

while(l)[ / * proceso de solicitud de servicio al servidor * / ' 1 ) ; printf ("Texto a enviar:

fgets (buf, MAX-LINE, stdin) ; / * envia datos */ if(send(s, buf, strleníbuf), O) c strlen(buf1 ) ( / * solicitud * /

perror("SEm: 11 ) ; break;

1 /* condicion de desconexion * / if (buf [O] =='Q' I I buf [ O 1 =='q' ) (

printf ("cliente termina conexion \n") ; close(s) ; /* cierra soket * / exit (O) ;

)

printf("C1iente en espera de respuesta del servidor ... \n"); / * recibe datos * / if((1en = recv(s, buf, MAX-LINE-1, O)) e = O)(

perror ( "RECV: 'I ) ; close(s); / * cierra socket * / exit (1) ;

1 buf [lenl = '\O' ; printf ("Respuesta servidor: %s \n\n", buf) ;

} / * fin while * / } / * fin main * /

La manera de compilar los programas desde la Enea de comandos del shell de UNM empleando el compilador de lenguaje C es la siguiente:

Cadl3% cc -o servidor servid0r.c Cadl4% cc -o cliente c1iente.c

La manera de ejecutar los programas desde el shell de U N E es como sigue, observe que la ejecución de cada programa se realiza en estaciones de trabajo distintas:

Cadl3% cc servidor Cadl4% cc cliente 148.208.92.100

110

La dirección I P 148.208.92.100 corresponde a la estación de trabajo Sun Spare denominada cud13 ubicada en el laboratorio de TAC (Trabajo Asistido por Computadora) del Cenidet.

11 Apéndice B: Programa Cliente en Windows

Este apartado contiene el código de un programa cliente escrito en UC++, el cual es capaz de conectarse al servidor en UNIX presentado en el apéndice A. El programa cliente aquí presentado uüliza llamadas a la API de WinSock, fue desarrollado en el cornpilador de Borland C++ 5.01 y probado en una PC con Windows 95 y Windows NT.

/* Cenidet



programa cliente usando sockets en pc * /

#include <windows.hs #include <winsock.hs #include <stdio.hs

#define MAX-LINE 120

char TCPIP-initialize(void) /* proceso de inicialización */

WORD WVersionRequested; / * versión WinCock.dl1 requerida * / WSADATA wsaData; /* estructura datos de inicialización * / int err; /* código de error * /

wVersionRequested = MIUcEWORD(1, 1) ;

err = WSAStartup(wVersi0nRequested. &wsaData);

if (err != O)(

(

/ * winsock.dl1 versión no disponible * / printf ("Inicializacion WINCOCK: ' I) ;

switchíerr){ / * averigua cual es el problema */

case WSASYCNOTREADY: printf("La red no esta lista para la comunicación.I');

break;

case WCAVERNOTSUPPORTED: printf("Versión no soportada por la implementación de

WINSOCK.") ; break;

case WCAEINVAL:

111

prlntf(T8Versión no soportada por W1NSOCK.DLL."); break;

default : printf ("No se. " ) ;

I return O; /* fracasa la inicialización de Winsock*/

) / / fin if

return 1; / * éxito en la inicialización de WinSock +/

] / * termina proceso'~.de'ini¿ialización de WinSock * /

void main0

char buf[MAX-LINEl; / * cadena de caracteres (datos) * / int len; /* longitud del buffer */

struct sockaddr-in fsock: char *host = "148.208.92.100"; / / dirección IP cad13 - TAC struct hostent *hent; / / guarda el llamado a gethostbyname0 int 6 ; / / identificador socket unsigned short puerto = 15000;

int error;

(

if(!(TCPIP-initialize()) ) [ / * inicialización de WinSock * / exit (1) ;

)

memset(&fsock, O, sizeof(fsock)); /* memoria para la estructura * /

/ * se obtiene la dirección IP del host donde se encuentra el servidor * / if(! (hent = gethostbyname(host))){

/ * en caso de fallo en gethostbyname0 */ /* recuperacion de fallo * /

unsigned long ipl,ip2,ip3,ip4;

if(sscanf (host, I' %d.%d.%d.%d", hipl,&ip2,&ip3,&ip4) == 4) [ / * este es un bug en algunas versiones de Windows * /

/ * la dirección IP numérica en la forma N.N.N.N */ /+ donde gethostbyname0 no puede entender * /

unsigned long ipaddr = //dir. IP rnaquina remota fsock.sin-addr.saddr = htonl(ipaddr);

[ (ip1<<241 1 (ip2<<16) 1 (ip3<c8) )ip4) i

/ / familia de direcciones fsock.sin-family = AF-INET;

/ / puerto de la maquina remota fsock.singort = (unsigned short)htons(puerto);

I else[ / / no sirve recuperación

printf ("gethostbyname: " ) ; error = WSAGetLastErrOr 0 ;

switch(error){ / * averigua el problema * /

112

case WSANOTINITIALISED: printf ( inwinsock No inicializado. " ) ;

break;

case WSAENETDOWN: printf('Fall0 en la red.") ;

break;

case WSAHOST-NOT-FOUND: printf ("NO se encontró el HOST.") ;

break;

case WSATRY-AGAIN: printf ("Falla del servidor. " ) i

break;

case WSmO-RECOVERY: printf ("Error no recuperable (refused) : " 1 ;

printf ("solicitud de conexión rechazada. " ) : break;

case WSANO_DATA: printf("N0mbre valido. No ahy registro de los datos."); break;

case WSAEINPROGRESS: printf("0peracion de bloqueo de socket en progreso.");

break;

case WSAEINTR: printf ("Llamada cancelada. " ) ;

break;

default : printf ("No se") ;

exit (O) ;

) / / fin else identificacion del error

) / / fin if gethostbyname0

else{ / / exito en la llamada gethostbyname0

/ / familia de direcciones fsock.sin-family = AF-INET; //dir. IP maquina remota fsock.sin-addr.s-addr = ((struct in-addr*) (hent->h-addr))-> s-addr; / / puerto de la maquina remota fsock. singort = (unsigned short) htons (puerto) ; ;

1 / * se crea un socket de flujo (stream) * / if ( ( S = socket (AF-INET, SOCK-STREAM, O) ) == SOCKET-ERROR) (

printf ("socket") ; exit (O) ;

)

/* solicitud de conexión al servidor * / if (connect i s , &fsock, sizeof (fsock)) == SOCKET-ERROR) (

113

printf ("connectl') ; closesocket ( s ) ; exit ( o ) ;

1 printf('Arranca programa cliente PC. Oprima 'Q' para terminar \n"); while(i)( /* ciclo de intercambio de datos */

printf ("Dame una cadena: "1 ; / * obtiene datos * / fgets (buf, MAX-LINE, stdin) ;

/* envía datos al servidor */ if( send(s, buf, strlen(buf), O) < strlen(buf) ) (

printf ("send" ) ; break; 1 / * condición de desconexión * / if(bufI01 == 'q' I I bufi0l == ' a ' > { exit ( O ) ;

printf ("Termina conexion") ;

1 printf ("Espero respuesta del servidor.. .\XI") ; / * recibe datos d e l servidor */ if((1en = recv(s, buf, MAXLINE-1 , 0 ) ) <= O)(

/ * terminó la conexión * / printf ("recv") ;

closesocket ( 8 ) ; WSACleanup í ) ; exit ( O ) ; 1 buf [lenl = '\O': printf re respuesta: as \n\n". buf) ;

} / / fin while ] / * fin main */

114

12 Apéndice C: Programas Cliente - Servidor DDE en Windows

Este apartado contiene el código de los programas cliente y servidor desarrollados en C++Builder. El programa servidor DDE soporta el enlace con múltiples clientes DDE, en las pruebas se incluyó ai paquete MatLab ver. 4.2 para Windows como aplicación cliente DDE. Las pruebas se realizaron en una PC con Windows 95 y Windows NT.

Un proyecto de aplicación en C++Builder se compone de varios archivos, a continuación se presentas los archivos fuentes principales del senidorDDE: - servidorddexpp, servid0rdde.h y ProjectServidorDDE.cpp.

Archivo: sewidordde.cpp

/ / . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ . ~ ~ ~ ~ ~ ~ ~ . ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ . ~ . ~ ~ - - - - - - - - - - - - - - - - - - - - - - - - - #include <vcl\vcl.h> #pragma hdrstop

#include "servidordde . h" / / aquí se pueden incluir variables globales / / .......................................................................

. #pragma resource "*.dfm" TForml *Fo?ml; I / forma o ventana de la aplicación / / ....................................................................... - fastcall TForml::TForml(TComponent* Owner)

{ 1 / / .......................................................................

: TForm(0wner)

void -fastcall TForml::DdeServerConvlOpen(TObject 'Sender) { / / evento OnOpen que se activa al abrirse un enlace DDE (DDELink)

ShowMessage ("Enlace abierto" i ; / / imprime cadena de mensaje 1 / / ....................................................................... void -fastcall TForml::DdeServerConvlClose(TObject *Sender) { / / evento Onclose que se activa ai cerrarse un enlace DDE

I / / .......................................................................

ShowMessage ("Enlace cerrado") :

void -fastcall TForml::DdeServerConvlExecuteMacro(TObject 'Sender,

( / / evento OnExecuteMacro que se activa para atender una orden TStrings *MS~)

/ / solicitada por un clienteDDE if (Msg-Strings 101 == 'Edit(C1ear') / / comando

Editl->Clear(); / I acción // mas comandos y acciones

1 / / ....................................................................... void -fastcall TForml::FormCreate(TObject *Sender) { / / esta sección corresponde al cuerpo principal del programa (main) / I se publica los datos de intercambio en el portapapeles

DdeCerveriteml-sCopyToClipboard(): DdeServeritem2-~CopyToClipboard~);

115

DdeServerItem3->CopyToClipboard(); DdeServerItem4->CopyToClipboard();

1 / / ....................................................................... void -fastcall TFOrmi::EditlChange(TObject *Sender) ( / / evento OnChange activado al modificar el valor del display // el valor del dato de intercambio es actualizado

DdeServerIteml->Text = Editl->Text; / / actualización ) / / -------------------.-.--.---.--..-----~~.~-..~-.~~-~..~-~.~~-~.--...--~

{

I / / .......................................................................

(

/ / -...--.-----...-------..~...-----...~----------------------------------

(

1

void -factcall TForml::Edit2Change(TObject *Sender) I

DdeServerItem2->Text = Editi->Text;

void -factcall TForml::Edit3Change(TObject *Sender)

DdeServerItem3->Text = Edit3->Text;

void -fastcall TForml::Edit4Change(TObject *Sender)

DdeServerIteml-,Text = Editl->Text;

----.-............-------.----------~--------------------------

Archivo: senid0rdde.h

//-----------.-----.-..-.--.-.-------------------.--.--.-.----------..-.- #ifndef servidorddeH #define servidorddeH

#include <vcl\Classes.hpp> #include <vcl\controls.hpp> #include <vcl\StdCtrls.hpp> #include <vcl\Forms.hpps #include <vcl\DdeMan.hpp>

class TForml : public TForm

qublished:

/ / .......................................................................

( / / IDE-managed Components (sección de componentes) TEdit *Editl; //componente de edición (display) TEdit *Edit2; TEdit *Edit3; TLabel *Labell; / / componente de etiqueta TLabel +Label2; TLabel *Label3; TEdit *Edit4; TLabel *Label4;

TDdeServerConv *DdeServerConvl; / / componente servidor de

TDdeServerItem *DdeServerIteml; TDdeServerItem *DdeServerItem2; / / datos de intercambio TDdeServerItem *DdeServerItem3; / / componente elemento TDdeServerItem *DdeServerItem4; / / de intercambio dinámico de datos

/ / conversación DDE

/ / sección de eventos void -fastcall DdeServerConvlOpen(T0bject *Sender); void -fastcall DdeServerConvlCiose(T0bject *Sender);

116

void -fastcall DdeServerConvlExecuteMacro(T0bject +Sender, TStrings *Msg) ;

void -fastcall FormCreate(T0bject *Sender) ; void -fastcall EditlChange(T0bject *Sender); void -fastcall EditZChange(T0bject *Sender); void -fastcall Edit3Change (TObject *Sender) ; void -fastcall EditlChange(T0bject *Sender);

private : / / User declarations public: / / User declarations

- fastcall TForml(TComponent* Owner); 1; / / ....................................................................... extern TForml *~orml; / / forma o ventana de la aplicación / / ....................................................................... #endif / / .......................................................................

Archivo: ProjectServidorDDE.cpp

#include cvcl\vcl.h> # p r a m hdrstop

USEFORM ("servidordde .cpp", Forml) ; USERES ("ProjectServidorDDE.res") ;

WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

/ / .......................................................................

/ / .......................................................................

{

Application->Initialize0 ; Application-zCreateForm(-classid(TFonnl), &Forml); Application->Run ( ) ;

I {

I

catch (Exception &exception)

Application->ShowException(&exception) ;

return O; I / / .......................................................................

117

En la figura C.1 puede apreciarse la vista del ambiente de desarrollo del C++Builder durante el diseño de la aplicación ProjectSeMdorDDE.

FiguraC.I.Di.seño del servidorDDE en C++Buüder.

A continuación se presenta el listado de la aplicación cliente DDE, los principales archivos que la componen son: clientedde.cpp, c1ientedd.h y ProjectClienteDDE.cpp

118

#pragma resource ),* .dfm" TForml *Forml: / / forma o ventana de la aplicación . . ~~ ~~ //-----------------.----..---.----.----..---.----------------------------

{ ) / / - - - - - - - -------..----..-----.----.-.--...--.-.--------------------------

void -fastcall ~~orml::~ormCreate(TObject *Sender) I//

fastCali ~ ~ ~ ~ m i : : ~ ~ o r m l ( ~ ~ o m p o n e n t * owner) - : TForrn(0wner)

sección corresponde ai cuerpo principal del programa (main)

/ / en el modo de conexión manual es necesario gue / / el ServidorDDE esté corriendo antes de / / ejecutar el clienteDDE

DdeClientConvl-.ConilectMode = ddeManual;

/ / ruta de la aplicación servidorDDE DdeClientConvl-s3erviceAppiication = String("C:\Archivo de

programas\Borland\CBuilder\Proyects\ProyectServidorDDE");

/ / establece programa de aplicación y tema para la conversación DDE

ShowMessage("SetLink"): / / definido aplicación y tema if (DdeClientConvl- >SetLink ( ' I ProyectServidorDDE" I "DdeServerConvl" ) )

/ / enlace con la aplicacion Servidor DDE if(DdeClientConvl-.PasteLink())

ShowMessage("PasteLink"): / / enlace DDE establecido

EditQ->Text = DdeClientConvl-SdeService; / / muestra programa servidor Edit3->Text = DdeClientConvl-sDdeTopic: / / tema de la conversacion DDE

1 / / ....................................................................... void -fastcall TForml::DdeClientitemlChange(TObject *Sender) { / / evento Onchange generado por una actualización / / en el valor del elemento de intercambio (dato)

/ / se despliega el valor del dato Editl->Text = DdeClientiteml->Text; / / dato de intercambio Edit2-,Text = DdeClientiteml->Ddeitem; / / nombre elemento

) / / ....................................................................... Void -fastcall TForml::DdeClientConviOpen(TObject *Sender) { / / evento OnOpen generado al abrir un enlace DDE

/ / nombre elemento a intercambiar (dato) DdeClientiteml->DdeItem = "DdeServeriteml"; / / solicita valor del elernento de intercambio DdeClientConvl->RequestData(DdeClientIteml-~DdeItem~;

DdeClientiternZ-,DdeItem = "DdeServeritem2"; DdeClientConvl-~ReguestData(DdeClientItemZ-~DdeItem);

DdeClientitem3-,Ddeitem = 'DdeServeritem3'; DdeClientConvl-~RequestData~DdeClientItem3-zDdeitem);

DdeClientitem4-,Ddeitem = "DdeServeritemQ"; DdeClientConVl-~RequestData~DdeClientItem4-~DdeItem);

I / / ....................................................................... void -fastcall TForml::DdeClientItem2Change(TObject *Sender) { / / evento Onchange activado al actualizarse el valor de intercambio

Edit5->Text = DdeClientItem2->Text; / / dato de intercambio

119

Edit2->Text = DdeClientItem2-,DdeItem; / / nombre elemento I

/ / --------------------------.--.---.----------.--.--...-~..-..--~.~~..-~~

(

I // .......................................................................

(

I / / .......................................................................

void -fastc’all TForml::DdeClientItem3Change(TObject *Sender)

Editó->Text = DdeClientItem3->Text; / I dato de intercambio EditZ->Text = DdeClientItem3->DdeItem: / / nombre elemento

void -fastcall TFOrml::DdeClientItem4Change(TObject +Sender)

Edit7->Text = DdeClientItem4-=Text; / / dato de intercambio EditZ->Text = DdeClientItem4->DdeItem; / / nombre elemento

void -fastcall TForml::DdeClientConviClose(TObject *Sender) ( / / evento OnClose activado al cerrarse un enlace DDE

Showblessage (“Termina enlace’’ ) ; I

Archivo: client4de.h

( published: J J IDE-managed Components (sección de componentes)

TEdit *Editl; TDdeClientConv *DdeClientConvl; / / cliente conversación DDE TDdeClientItem *DdeClientIteml; / / elemento de intercambio TEdit *Edit2; TEdit *Edit3; / / componente de edición (display) TLabel *Labell; TLabel *Label2; / / componente etiqueta de texto TLabel *Label3; TEdit *Edit4; TLabel *Label4; TEdit *Edit5; TEdit *Edit6; TEdit *Edit7; TLabel ‘Label5; TLabel *Label6; TLabel *Labe17; TDdeClientItem *DdeClientItem2; / / elemento de intercambio TDdeClientItem *DdeClientItem3; TDdeClientItem *DdeClientItem4; void -fastcall FormCreate(T0bject *Sender);

120

/ / sección de eventos

void -fastcall DdeClientItemlChange(T0bject 'Sender) ;

void -fastcall DdeClientConvlOpen(T0bject +Sender); void -fastcall DdeClientItemiChange(T0bject *Sender): void -fastcall DdeClientItem3Change(TObject *Sender); void -fastcall DdeClientItem4Change(TObject *Sender):

void -fastcall DdeClientConvlClose(T0bject *Sender) ;

private: / / User declarations public: / / User declarations

- fastcall TForml(TComponent* Owner) ; 1; / / ....................................................................... extern TForml *Forml; // forma o ventana de la aplicación / / ....................................................................... #endif

1 ( catch

Application->Initialize(); Application->CreateForm(-classid(TForm1) , &Forml) ; Application->Run();

(Exception &exception)

Application->ShowException(&exception) ;

121

En la figura C.2 puede apreciarse la vista del ambiente de desarrollo del C++Builder durante el diseño de la aplicación ProjectClienteDDE.

Figura C.2. Diseño del clienteDDE en C++Builder.

Observe que los componentes para conversaciones DDE se encuentran en la paleta System de menú de herramientas de C++Builder.

El servidor DDE soporta también programas clientes en MatLab. A continuación se presentan un listado con ejemplos de las funciones utilizadas en el entorno de MatLab para realizar el intercambio de datos con el servidor DDE.

% ejemplo de funciones del toolbox dde en MatLab

% obtiene un canal de comunicación con un servidor DDE x chanel = ddeinit('ProjectServidorDDE','DdeServerConvl') chanel = 4.1883e-309

% solicita un el valor de un elemento de intercambio D dl = ddereq(chane1,~DdeServerIteml')

122

dl = 12 B d2 = ddereq(chanel,'DdeServerItem2' d2 = 34 n d3 = ddereq(chanel,'DdeServerItem3' d3 = 56 B d4 = ddereq(chane1, 'DdeServerItem4' d4 = 789

% soporta múltiples canales de comunicación con otros servidores DDE % canal = ddeinit('ProjectServidorDDE<.'DdeServerConvl') canal = 4.1883e-309

n a4 = ddereq(chanel,'DdeServerItem4*) a4 = 789

* a4 = ddereqlchanel,'DdeServerItem4') a4 = 321

D dl dl = 12

% envía al servidor DDE un nuevo valor para el dato de intercambio * rc = ddepoke(canal,'DdeServerItem1',100.99) rc = 361725952 % comprueba la actualización del dato en el servidor DDE

dl = 100.9900

D rc = ddepoke(canal,'DdeServerIteml',O.l23) rc = 98304 n dl = ddereq(chane1,'DdeServerIteml') dl = 0.1230

% cierra el enlace de comunicación DDE 2 rc = ddeterm(cana1) rc = 1

dl = ddereq(chane1,'DdeServerIteml')

>

123

13 Apéndice D: Programa Pick and Place

Este apartado contiene el código para ejecutar una tarea típica depick andplace con el robot articulado CRS modelo T476. El programa esta escrito en lenguaje RAPL II, el cual esta basado en comandos y su sintaxis es similar al lenguaje de programación BASIC. El programa utiliza tres variables de localización (A$ y c) y tres valores constantes (ADIST, BDIST y CMAX)que fueron definidos con el editor de variables de localización y con el editor de variables del software Robcomm, respectivamente. Para la ejecución del programa es necesario cargar el programa al controlador C500 del robot.

Se probó en una PC con procesador Pentium con 32 Mb en RAM, con los sistemas operativosWindows 95/98 y con Windows NT.

; Cenidet


; tesis: esquema para la integracion de sistemas de visión robótica

; programa: Pick and place

SPEED 100 ; define velocidad ! C = O ; inicializa contador10 APPRO A,ADIST

MOVE A ; se dirige a alcanzar al punto A FINISH ; espera a que concluya el movimiento CLOSE ; cierra la pinza del griper para sujetar DEPART ADIST ; se aparta a cierta distancia sobre el eje Z APPRO B,BDIST ; se aproxima al punto B a una cierta distancia MOVE B ; se dirige a alcanzar al punto B FINISH ; espera a terminar el movimiento OPEN ; abre la pinza para soltar DEPART BDIST ; se aparta a cierta distancia sobre el eje 2 ++ c ; incrementa contador en uno IF C c CMAX THEN 10 ; condición de ciclo, salta a etiqueta 10 READY ; posición de listo RETURN ; fin del programa

; aproxima al punto A hasta una cierta distancia

c

124

La siguiente figura muestra el editor de variables de localización del software Robcomm, las cuales también tienen que cargarse, junto con el programa y los valores constantes en el controlador G O O .

125

ESQUEMA PARA LA INTEGRACION DE SISTEMAS DE VISION ROBOTICA Edson Ignacio Peralta Abundes

julio 2003

¿Cómo aplicar el esquema y las interfaces propuestas para tareas de control?

A I Y !

Obietivo

X ---------------- -b

Tarea de Pick and Place en Módulo Cliente

1 lnicializar robot articulado 1.1 Llevarlo a posición home inicial 2 Localizar visualmente el objetivo 3 Trazar trayectoria movimiento 3.1 Algoritmo plantación de rutas con obstáculos 4 Ordenar movimiento hacia el objetivo 5 Confirmar visualmente la posición del efector sobre el objetivo 5.1 Algoritmo de ajuste de la posición 6 Ordenar el agarre 6.1 Confirmar visualmente el agarre

Programación del Ciclo de la Tarea

1 main O ( 2 Define variables x, y, z, r, p, w; 3 inicializar-robotlT476); 4 5 deposito(id-contenedor. xi y, z , r, p, w); 6 posicion contenedor = defineqosicion("contenedor", x, y, z . r, p, w); 7 8 8.1 8.2 8.3 8.4 8.5 8.6 8.7 9

while lcondicion-salida) ( localiza-objeto(id-objetivo, x, y, z, r, p, w); punto-agarrelid-objetivo, x, y, z , r, p, w); posicion objetivo = definegosicion1"objetivo". x, y, z, r, p , w); abrir-efectorl10); trasladalobjetivo, 1); localiza-gripperlid-gripper, x , y, z, r. p ,w): posicion efector = definejosicion("efector", xi y, z , r, p, w);

10 while lefector i = objetivo) ( 10.1 ajustargosicionlx, y, z , O ) : 10.2 efector = posicion-actual1"efector"); 10.3 I / / fin while interno 11 11.1 cerrar-efector(l0); 11.2 trasladalcontenedor); 12 ) / / fin while externo 13 14 finalizar-robot(T476); 15 1 / / fin main 16 17 OnEventoIevento) ( 18 if levento == id-objeto-desconocido) í / / obtaculo 18.1 localiza-objetolevento, x, y, z, r, p, w); 18.2 / / ajusta la trayectoria para evitar obstaculo 18.3 punto via = defineqosicion("via", y, x, z, r, p, w); 18.4 traslada-viaíobjetivo, via); 19 I 20 if levento == id-objetivo) ( / / cambio de posicion 20.1 rastrearlobjetivo, x, y, z . r, p , w); 20.2 objetivo = defineqosicion("ob3etivo". x, y, z, r, p, w); 21 1 22 I / / fin OnEvento

Documents

CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO … · 2014-02-13 · s.e.p. s.e.i.t. d. gi. t. centro nacional de investigaciÓn y desarrollo tecnolÓgico cenidet esquema para laintegraciÓn