123-~

, TECNOLOGICO DE MONTERREY®

Instituto Tecnológico y de Estudios Superiores de Monterrey

Campus Ciudad de México

División de Ingeniería y Arquitectura

Ingeniería en Sistemas Electrónicos

Departamento de Ingeniería Eléctrica y Electrónica

FIRA EVO: Diseño de las Tarjetas de Control y Potencia de un Robot Móvil de la

asociación FIRA/Mirosot

Autores:

Asesor:

Coasesor:

Marco Tulio González Astorga Christian García Chávez

Dr. Ernesto Olguín Díaz

lng. Cristian Tena

717828 954404

México D.F., 3 de diciembre de 2004

'E G 1A_ PRoL(E

TJ").11. 35 ~~b

P,.oo',

Índice Capítulo 1: Introducción al proyecto

1.1 Resumen 1.2 Descripción del proyecto 1.3 Desarrolos Anteriores 1.4 Objetivos 1.5 Justlk:aclón y Alcance del proyecto

Parte 1 Estuclo del Mlcroc9'*olador

Capítulo 2: Sistema basado en AVR 2.1 Descripción del AVR 2.2 Descripción del prototipo en AVR 2.3 Desventajas

Capítulo 3: Sistema basado en DSP 3.1 lldroducclón al DSP 3.2 Estado del Arte 3.3 Ventajas del DSP 3.4 ANi1sis del MC56f8323 de ffeescale de Motorola

Parte 2 Telecomunicaciones

Capítulo 4: Módulos de comunicación RF 4.1 Prablemállca 4.2 Diseño del sistema de comunicación 4.3 Proceso de decocllcac:lón de •ca1N1 lf

Parte 3 Diseño ele Prototipo

Capítulo 5: Tarjeta de Potencia 5.1 Propuesta de Esquemállco Al•edar 5.2 leclseño en el Esquemático U Consldlllaclone FÍlieas 5.4 1lmra Aldóglca 5.5 Diseño de la TClljeta de Circulo Impreso

Capítulo 6: Tarjeta de Control 6.1 Prop1N!Sla de EsqlNNllállco Al•alar 6.2 Rediseño en el Esquemático 6.3 Calllidetaclones FÍlieas 6.4 TJerra Dlgllal 6.5 Diseño de las .-ilm 6.6 Conul6n con módulo de IF 6.7 Conexión con la Tmjeta de~

Parte 4 Implementación

Capítulo 7: Implementación de la Tarjeta de Potencia

7.1 Circuito Impreso 7.2 Montaje de Componentes 7.3 Pruebas

Capítulo 8: Implementación de la Tarjeta de Control

8. 1 Circuito Impreso 8.2 Montaje de Componentes 8.3 Montaje del DSP 8.4 Programación del DSP as Consideraciones de la Implementación

Capítulo 9: Conclusiones y Perspectivas

Capítulo 1 O: Referencias

Capítulo 1

Introducción al Proyecto

1.1 Resumen

En este proyecto se busca diseñar e implementar un sistema analógico­digital basado en un Procesador Digital de Señales (Motorola 56F8323), que permita controlar un robot móvil de tres grados de libertad (dos coordenadas generalizadas, controladas) que de manera autónoma juegue un partido de fútbol soccer bajo las normas establecidos por la asociación FIRA 1•

Se parte de una base de conocimiento y desarrollo tecnológico lograda en instancias anteriores del proyecto, principalmente en las áreas de:

• Telecomunicaciones

Mediante el uso de equipo de radio frecuencia se busca exista comunicación entre la computadora de control y el robot para su manejo. Se deben validar los resultados obtenidos en su momento, en relación a la migración de sistemas y reemplazo de componentes.

• Control Automático

Implementando leyes de control que permitan una mayor eficiencia en el consumo del robot así como una mayor rapidez y precisión en los movimientos del robot. Para ello se cuenta de antemano con el modelado de la planta y leyes de control adecuadas para la misma, desarrolladas por alumnos del Tecnológico de Monterrey CCM, como parte de su Proyecto de Ingeniería [3].

• Procesamiento Digital de Señales

Buscando emigrar el sistema de control desarrollado en la etapa anterior a una arquitectura digital de mayor escala de integración así como de mayor funcionalidad tanto en el poder de cómputo como en la capacidad de sensado.

I ARA: Football lnlemational Robots Association.

- 1 -

1.2 Descripción del Proyecto

La asociación FIRA (Football lnternational Robot Association) es el organismo encargado de la organización año con año, de un torneo internacional de diferentes categorías de robot para disputar un juego de fútbol soccer [7].

Dentro de estas múltiples categorías, se encuentra la que comprende los alcances de este proyecto. Mirosot, es la categoría que comprende la competencia en equipos de cinco robots de 75mm por lado para cada equipo controlado por radio frecuencia y sensado a través de un sistema de percepción basado en una cámara a colores, cenital, que adquiere tomas superiores del campo de juego.

El Tecnológico de Monterrey, Campus Ciudad de México cuenta con unidades Mirosot de la compañía Yujin Robotics, del modelo YSR-A. Dichos robots se componen, en cuanto a la electrónica se refiere, de una etapa de comunicaciones, control y potencia, que en conjunto con el par de motores montados en el bloque de la planta forman la unidad.

Como se mencionó anteriormente, juegan un papel clave tanto el área mecánica y electrónica de potencia, en cuanto a lo que se refiere a los motores así como la electrónica digital y telecomunicaciones en los circuitos de control y comunicación necesarios. Existe gente dedicada al análisis de las imágenes adquiridas por el sistema de percepción así como computólogos dedicados al desarrollo de sistemas inteligentes para el control y toma de decisiones del equipo.

Cabe destacar que este proyecto fue comenzado por iniciativa conjunta del Tecnológico de Monterrey, Campus Cuernavaca y Campus Ciudad de México por los investigadores Dr. Enrique Espinosa y Dr. Fernando Ramos. Se comenzó la investigación hace varios años enfocándose principalmente en la llamada robótica suave del mismo, es decir el sistema de toma de decisiones para robots multiagentes.

1.3 Desarrollos Anteriores

Durante las fases anteriores del proyecto se encontró que el modelo del robot presentaba deficiencias debido al consumo de corriente y los tiempos de respuesta en los motores, lo que redundaba en un pobre desempeño en los algoritmos diseñados para su interacción. Además no se tenía acceso para poder programar diferentes algoritmos de control dentro del sistema del robot. Por ello para los proyectos [2] y [3] de los FIRA se puso mayor énfasis en la descripción del modelo dinámico del robot así como la sintonización de leyes de control. Dicho desarrollo buscaría por un lado brindar un mejor

- 2 -

desempeño en cuanto a velocidad y precisión del robot, así como limitar las demandas de corriente en la etapa de potencia.

Por otro lado, la etapa de telecomunicaciones por radiofrecuencia sufrió modificaciones desde los bloques receptor y transmisor implementados de acuerdo a un análisis de la relación señal a ruido en los módulos originales así como la tasa de envío permitida.

Sin embargo, la implementación del prototipo anterior, no cumplía cabalmente con diversas especificaciones de diseño, especialmente las referentes a espacio físico y potencial de uso. Parte principalmente sobre la elección de microcontroladores grandes con respecto al módulo FIRA además de limitados en capacidades que redundaron en una implementación que aunque funcional no resultaba práctica, pues mantenía de forma muy aislada las diferentes etapas del robot, así como el mantenimiento de los mismos.

1.4 Objetivos y Metas

1. Desarrollo de la Tarjeta de Circuito Impreso del robot YRS-A de Yujin Robotics que cumpla con los siguientes requisitos:

• Módulo de Control

o Sensado de la corriente de cada motor, mediante la conversión de dos señales analógicas a valores digitales.

o Generación de señales PWM para definir el voltaje promedio que alimentará a cada motor.

o Temporización a intervalo constante para ejecución del algoritmo de control.

o Determinación del sentido real de giro y de la velocidad de cada rueda a partir de las señales de cuadratura proporcionadas por los codificadores incluidos en los motores.

o Capacidad para decodificar la trama recibida del módulo de radiofrecuencia.

o Empleo de dos pines para controlar el sentido de giro de cada motor (control de dirección de la corriente en el puente H de la etapa de potencia).

o Programación in situ para permitir la implementación de otros tipos de algoritmo de control.

• Módulo de Telecomunicaciones o Transmisión y recepción de comandos a los robots mediante

radiofrecuencia. o Software para envío de información desde la computadora al

módulo de radiofrecuencia.

- 3 -

• Módulo de Potencia o Alimentación de los motores, proporcionando hasta 7.4V o Alimentación de los circuitos involucrados en el control y

recepción de radiofrecuencia

2. Migrar el sistema digital a una arquitectura basada en un DSP de Motorola.

3. Validar los algoritmos de Control diseñados en proyectos anteriores. 4. Modificar la codificación de los datos contenidos en la trama de

radiofrecuencia a fin de maximizar el universo de posibles referencias de velocidad.

5. Ajustar las dimensiones de las tarjetas a fin de que puedan montarse en el interior del robot.

1.5 Justificación y Alcance del Proyecto

1.5. 1 Justificación

La implementación realizada durante el proyecto reportado en [2], consistió en el primer prototipo construido con el propósito de probar la validez de los algoritmos de control desarrollados, así como la comunicación a través del nuevo sistema de radiofrecuencia que se incorporó. Sin embargo, entre las directrices del diseño, no se consideró las limitaciones físicas inherentes al espacio interno del robot, por lo que la selección de componentes, en su mayoría, no resultan prácticos en una implementación definitiva.

Así pues, surge la necesidad de rediseñar a partir del esquema de funcionamiento propuesto, un sistema de un mayor nivel de integración, fiabilidad de operación y acotado a las características mecánicas propias del módulo Mirosot.

1.5.2 Alcance

La meta del proyecto es implementar el sistema digital completamente operativo en tarjetas de circuito impreso que sean montables en el interior del módulo FIRA/Yujin.

El módulo deberá haber validado tanto la comunicac1on con la computadora, así como la Ley de Control y la eficiencia en consumo de potencia. Dicho sistema será estandarizado como el módulo de jugador base para todos los equipos FIRA del Sistema Tec de Monterrey.

El software necesario para la comunicación con los robots se propone como un conjunto de recursos reutilizables bajo el API J2SDK (6] en código abierto para su futura revisión y posible expansión.

- 4 -

PARTE 1

ESTUDIO DEL MICROCONTROLADOR

Capítulo 2: Sistema basado en A VR

2.1 Descripción del A VR

El microcontrolador A VR 9058515 de Atmel de 8 bits, construido con tecnología CMOS de alta velocidad, constituye uno de los componentes de mayor importancia en el prototipo desarrollado en el proyecto de ingeniería de IEC del semestre enero-agosto de 2004, puesto que realiza las funciones de control.

Este circuito ofrece varias características que lo hacen confiable en aplicaciones de control, proporcionando una opción efectiva en costos. Emplea una arquitectura tipo RISC (Reduced lnstruction Set Computer) de alto desempeño, mediante la implementación de 118 instrucciones que en su mayoría se ejecutan en un ciclo de reloj. operando a una frecuencia de hasta 8 Mhz. La arquitectura resultante permite que el chip sea capaz de ejecutar las instrucciones de programa hasta diez veces más rápido que los microcontroladores RIC. Asimismo, el microcontrolador es reprogramable en sitio mediante la interfase SPI.

Entre sus características principales se encuentra la variedad de periféricos que incorpora, entre los que se puede mencionar:

• Un timer/counter de 8 bits • Un timer/counter de 16 bits. con capacidad de generar dos señales de

PWM. • Interfase de comunicación UART • Interfase serial amo/esclavo SPI • Hasta 32 líneas programables de entrada y salida

- 5 -

2.2 Descripción del prototipo en A VR

El prototipo desarrollado emplea dos microcontroladores AVR 90$8535 (llamados microprocesador de control y microcontrolador de sensado) y un PIC 16F67 6 para satisfacer la mayor parte de las labores descritas en el apartado 1 .4 del módulo control [2].

En dicho dispositivo, el microcontrolador PIC 16F67 6 se empleó para realizar la decodificación de la trama procedente del módulo RF, enviando posteriormente los datos correspondientes al microcontrolador A VR encargado de ejecutar las labores de control. Por su parte el microcontrolador de control al requerir la información de la corriente y la velocidad para llevar a cabo su labor, obtiene los datos necesarios mediante la comunicación con el otro AVR, encargado del sensado de las variables de interés, mediante el uso de un bus de ocho líneas.

2.3 Desventajas

Las principales razones que motivaron la implementación ante mencionada son la falta de periféricos internos de un único chip para cumplir las labores de medición, temporización y decodificación de la trama captada por el módulo RF, además de la sobrecarga que significaría (en el hipotético caso de contar con los periféricos no disponibles) para un solo microcontrolador con las características del AVR8535 (frecuencia de operación, manipulación de interrupciones, capacidad de cálculo de la ALU, tamaño de registros, entre otros) la ejecución de todo el código necesario.

A pesar de que el prototipo es completamente operacional y probó tener un desempeño adecuado, existen características del mismo que deben ser mejoradas a fin de contar con un diseño de mayores prestaciones. La principal desventaja del diseño radica en que el espacio requerido para albergar a todos los componentes involucrados, excede por mucho (en todas dimensiones) el disponible en el interior del robot.

Por otra parte en dicho diseño no se cuenta con la capacidad (aun empleando un microcontrolador para la labor de medición) de verificar la dirección real de giro de cada motor puesto que no se emplea la señal procedente del segundo encoder de cada motor.

-6-

Capítulo 3: Sistema basado en DSP

3.1 Introducción al DSP

Partiendo del análisis realizado en el capítulo anterior, uno de los aspectos de mayor importancia a considerar en el presente proyecto en el área de desarrollo del sistema de control, fue la elección del elemento central de procesamiento. Dicho elemento resulta crucial puesto que es el encargado de obtener la información procedente del módulo de telecomunicaciones, realizar la medición de las variables de interés (velocidad y la corriente) y ejecutar la ley de control del robot. Es decir, debe ser capaz de satisfacer cabalmente todos los requisitos mencionados en el apartado referente a los requisitos del sistema de control.

Dado que resulta necesario max1m1zar el espacio disponible, resulta imperativo que el dispositivo de procesamiento cuente con la capacidad de cálculo suficiente para que la realización de las operaciones matemáticas no generara retraso en las demás áreas de procesamiento. Asimismo resulta necesario que el controlador cuente con los periféricos suficientes para llevar a cabo las labores de entrada y salida, de modo eficiente, empleando el menor número de componentes externos para solventar dichas funciones.

Con base en las consideraciones anteriores resulta difícil encontrar un microcontrolador que logre cubrir completamente con los requisitos del proyecto, por lo que se tomó la decisión de emplear un Procesador Digital de Señales (Digital Signal Processor) con especialización en aplicaciones de control.

3.2 Análisis del MC56F8323

Motorola, compañía líder en el área de los DSP, ofrece varias familias de estos dispositivos que se acomodan a diversos tipos de aplicaciones. Entre dichas series se seleccionó a la familia 56F800E puesto que se distingue por contar con una arquitectura híbrida (tipo Harvard) diseñada para facilitar el desarrollo de aplicaciones de control y procesamiento de señales en un solo dispositivo.

En particular, la arquitectura híbrida antes mencionada es una de las características que influyó de forma definitiva en la selección de esta serie, puesto que se reúnen las mejores cualidades de los DSP, al proporcionar una formidable capacidad de cálculo y gran velocidad de ejecución, así como la versatilidad de un microcontrolador al incluir un gran número de periféricos. Asimismo la arquitectura del controlador junto con su conjunto

- 7 -

de instrucciones, permiten la generac1on de código compacto y muy eficiente por parte de compiladores de lenguaje C.

Así pues habiendo definido la serie a emplear se decidió que en particular el DSP MC56F8323 es el que mejor se acomoda al proyecto por su bajo costo y por sus características funcionales y espaciales, entre las cuales podemos enlistar las siguientes:

• Hasta 60 MIPS a 60MHz de frecuencia de núcleo • 32KB de memoria Flash de programa • 4KB de memoria RAM de programa • BKB de memoria Flash de datos • BKB de memoria RAM de datos • BKB de memoria Flash para inicialización(Boot) • Un módulo PWM de 6 canales • Dos ADC de 4 canales, de resolución de 12 bits • Un decodificador de cuadratura • Un módulo FlexCAN • Hasta dos interfases de comunicación serial (SCI) • Hasta dos interfases de periférico serial (SPI) • Dos módulos cuádruples de temporizadores de 16 bits • Oscilador interno • Interfase para de depuración no intrusita en tiempo real

JTAG/Enhanced On-Chip Emulation (OnCfTM) • Hasta 27 líneas de entrada y salida de propósito general • Encapsulado LQFP de 64 pines • Fabricación en CMOS de alta densidad con tolerancia a 5V,

compatible con entradas digitales TTL • Regulador interno de 3.3V a 2.6V para energizar las memorias internas. • Reguladores internos para circuitería analógica y digital para

reducción de costos y ruido. • Capacidad de configurar cada periférico para ahorro de energía. • Programación en sitio • Tres unidades de ejecución funcionando en paralelo.

Así, a partir de los periféricos y características del DSP se pueden satisfacer los requisitos de control mediante el uso de:

• Dos canales del ADC para sensado de corriente • Uso de dos canales de PWM para definición del voltaje del motor • Uso de un temporizador para establecer intervalo de muestreo • Determinación de sentido real de giro y de velocidad de los motores

mediante el uso de dos temporizadores en modo de conteo de cuadratura

• Decodificación de trama RF mediante una línea de entrada/salida en modo de interrupción en conjunto con un temporizador.

- 8 -

• Uso de cuatro líneas de entrada/salida para determinar el sentido de giro de cada motor en el puente H

• Programación en sitio mediante comunicación serial

Si se comparan los recursos empleados con las capacidades del DSP, se puede observar que el dispositivo cumple fácilmente con los requisitos establecidos.

Otro aspecto que apoyó la selección realizada es el costo reducido de desarrollo en torno al dispositivo, en cuanto a hardware y software necesarios, puesto que en el Departamento de Ingeniería y Arquitectura se cuenta con algunas tarjetas de demostración en torno al DSP seleccionado ( donadas por Freescale) y además se incluye el entorno de desarrollo CodeWarrior.

Habiéndose definido al controlador MC56F8323, como dispositivo medular para la tarjeta de control, queda abierta la posibilidad de implementar algoritmos de control más complejos sin necesidad de realizar modificaciones de hardware.

- 9 -

PARTE 2 TELECOMUNICACIONES

Capítulo 4: Interfase de Comunicación PC-RF

4.1 Problemática

En el proyecto de ingernena de IEC[2], se empleó un módulo de comunicación entre la PC y el transmisor basado en interfase USB. Dicho dispositivo resultó de la modificación del kit de desarrollo para radiofrecuencia rf PIC de Microchip.

Para la operación del kit como parte de dicho proyecto, se cambió el programa del microcontrolador PIC encargado de la comunicación USB, a fin de interactuar con el programa desarrollado. Asimismo, mediante el empleo de dicho dispositivo se reprogramó el transmisor ASK incorporado para definir el protocolo de la trama a enviar.

Sin embargo, aunque dicho bloque ya se encontraba en estado operativo, no es posible emplearlo en el presente proyecto puesto que por cuestiones ajenas al desarrollo del mismo, el dispositivo ya no está disponible por lo que se tomó la decisión de descartarlo y reimplementarlo.

4.2 Diseño del sistema de comunicación

Dada la problemática mencionada en el punto anterior, se necesitó la implementación de un dispositivo que realizará las mismas funciones (recepción de datos de la computadora y transmisión por radiofrecuencia).

Para ello se realizó la migración de interfase USB a serial RS232 (comunicación UART) ya que es un estándar bien conocido y disponible en prácticamente cualquier microcontrolador. Así, se decidió emplear como intermediario entre la computadora y el transmisor rf PIC l 2F67 SK un microcontrolador AT90S23 l 3, mostrado en la figura (uno de los más compactos de la familia A VR) ya que cuenta con la interfase antes mencionada. Además, puesto que el transmisor requiere únicamente dos líneas para recibir los datos que ha de enviar no se requiere de un microcontrolador con varias funciones o muchos puertos.

Dado que el protocolo empleado en la comunicación inalámbrica de datos se encuentra programado en el transmisor, proceso realizado con el módulo no disponible, en el presente proyecto únicamente se emplea el formato

- 10 -

que está predefinido. Es decir, únicamente se cuenta con diez bytes de datos para indicar la velocidad de cada motor y un onceavo byte para verificación de integridad de la información mediante un cheksum, empleando la codificación del segundo esquema de transmisión definido en [2].

PDIP:SOIC

IEIET VQ:

(UD) - l'U (ICII) (TJIDI l'D1 l'N (IIIIIO}

nAL.2 .... (IIOII) nAL1 Pl4

PIITDJ 1'112 PII (OC1) PITI) ~ Pl2

CTDI PD4 f'a1 i,.1•11 (Tt) PD5 ... (AIIIO)

(N) ..._ __ • 1'111 (ICI')

Figura 4.2.1 Configuración de pines del AT90S2313 [8)

Dadas las restricciones impuestas por el transmisor, únicamente se pueden recibir diez bytes de datos de la computadora, que han de ser transmitidos bit a bit al transmisor el cual al finalizar la recepción calcula y agrega el byte once y transmite la trama en modulación ASK.

Ya que el módulo implementado funge como centro de comunicaciones, se decidió añadirle un bloque independiente que se puede emplear en conjunción con la tarjeta de control a fin de emplear las capacidades de comunicación serial del DSP y llevar a cabo la programación en sitio. Dicho bloque únicamente proporciona una interfase mecánica mediante dos conectores DB9 hembra y también realiza el acondicionamiento del nivel de las señales de RS232 a TIL.

rfPIC12F675K 315 Mhz

AVR90S2313

Sección de transmisión por radiofrecuencia

Conector DB9 hembra

1

Interfase de niveles RS232 a

m

lnterfa!le de niveles RS232 a

TTL

Sección para comunicación serial con DSP en tarjeta de

control

Figura 4.2.2 Diagrama de bloques del módulo de comunicaciones y programación

- 11 -

4.2.1 Rediseño del software para comunicaciones.

Como se mencionó en el apartado anterior, el cambio de interfase y la no disponibilidad del módulo de transmisión basado en USB trajeron consigo otra consecuencia en torno al software empleado para definir y enviar la información al dispositivo de transmisión. El programa con el que se contaba resultó ser completamente incompatible con la nueva implementación y de estructura inherentemente cerrada, con lo que en esencia dicho código resulta difícil de depurar y no reutilizable.

Así, se buscó crear un nuevo software de estructura abierta, reutilizable y fácil de emplear. Para ello se decidió cambiar de lenguaje de programación de C a Java[9], puesto que este último ofrece un gran conjunto de bibliotecas de componentes gráficos para construir aplicaciones rápidamente, también cuenta con una extensión del lenguaje que permite emplear los puertos serie y paralelo de la PC.

El código creado para sustituir al anterior consta de dos bloques principales el módulo de comunicación serial y la interfase gráfica. Se decidió emplear este diseño, para permitir que aplicaciones futuras que incorporen inteligencia a los robots se desarrollen sin preocuparse de la comunicación con el hardware al emplear únicamente el módulo de comunicación serial.

El desarrollo del componente encargado de la gestión de la comunicación serial, se realizó a partir de las capacidades y servicios ofrecidos por el paquete javax.comm[9]. Dicho paquete constituye una extensión del lenguaje proporcionada por Sun Microsystems.

La interfase gráfica del programa desarrollado (figura 4.2.1 .1) tiene como propósito permitir la definición de cada uno de los bytes que componen la sección de la trama relacionada con velocidades, de acuerdo al protocolo definido en 4.2.2 , ofreciendo una serie de funciones para facilitar la fase de pruebas de comunicación y control.

Byte1

Byte3

Byte5 ~ -i-~~~Rlllllrttl.----.-~ ~:==:i::i-~~~-f-~ Byte6

Byte? Bytes

Byte9 Byte10

Envío periódico Envío único Trama aleatoria Limpiar trama

Paro de emergencia

Figura 4.2.1.1 GUI del programa para comunicación con transmisor

- 12 -

Entre dichas funciones se encuentran la definición de referencias de velocidad de forma aleatoria, la creación de un grupo de referencias con valor cero, el envío único de un grupo de datos y el envío periódico de la información definida en los campos.

4.2.2 Protocolo de transmisión e interpretación de datos

Con el propósito de mantener un esquema consistente durante todo el proceso de envío de datos, se definió el orden y significado de los diez bytes de datos disponibles en cada trama.

Dado que se requiere enviar referencias de velocidad a los robots, cada dato debe identificar la magnitud y sentido deseados de acuerdo al formato mostrado en la figura 4.2.2.1. Así, se estableció que en cada byte el bit más significativo define el sentido, donde "1" corresponde a una velocidad negativa, es decir que el resultado de la acción del motor al cual se dirige la referencia debe contribuir a desplazar al robot hacia atrás. En cuanto a la magnitud, únicamente se pueden asignar 128 posibles referencias (valores de O a 127).

LSB MSB

Bit1 Bit1 Bit3 Bit4 I Bit5 Bit6 . 1

Bit7 BitB ' . J Magnitud de la referencia de velociad Signo .... ......,.._ ...

Figura 4.2.2.1 Formato de byte correspondiente a referencia de velocidad

Con dicha restricción se estableció que a fin de abarcar un universo mayor de velocidades, se multiplica cada valor de magnitud por dos(en el DSP) a fin de obtener referencias en el intervalo de O a 254. Así, el intervalo completo de valores posibles para codificar velocidades abarca desde -254 hasta 254.

A partir de dicha implementación se pierden todos los valores impares de referencias; pero se obtiene la ventaja de contar con un rango más amplio de velocidades. Además resulta casi imperceptible, en términos prácticos, apreciar la diferencia en el comportamiento del robot al proporcionar referencias muy similares, como en el caso de valores codificados adyacentes.

Asimismo, se estableció que los diez bytes de datos con referencias se organizaran de acuerdo al esquema de la figura 4.2.2.2, donde las velocidades para los motores de cada robot se agrupan de forma continua, desde el robot con identificador 1 hasta el 5. En cada par de referencias, la primera corresponde a la velocidad deseada para el motor izquierdo del robot en cuestión y la siguiente al valor deseado de velocidad para el motor derecho.

- 13 -

~ ~ ~ ~ ~ ' ~ ~ ~ ~ ~ ....... ...,._ ....... ....... ~ ......__ ~- ....... ___ ....... ----... 1

Byte1 Byte2 Byte3 Byte4 Bytes Bytes Byte9 Byte10

... Vel. Rot>c>t1 -· Vel. Robol2 __ .,:... Vel. Robot3 .,.¡.,._'\/el. Robot4 - Vel. Robots

Figura 4.2.2.2 Organización de las referencias de velocidad

4.2.3 Transmisión de datos de AVR a transmisor ASK

El envió de la información al transmisor por parte del microcontrolador se realiza de la siguiente manera.

Al recibirse los diez bytes desde la computadora por la interfase UART, se comienza a enviar el bit menos significativo del primer byte, colocándolo en el pin PBO(conectado al pin 7 del transmisor). asimismo se coloca en el pin PB 1 el pulso de reloj que recibe el transmisor para aceptar el dato(pin 8). Dicho pulso tiene una duración de 40 µs en nivel alto y 40 µs en nivel bajo.

El proceso se repite hasta enviar los bits restantes del primer byte, luego de lo cual se continúa con los sucesivos hasta finalizar enviando el bit más significativo del último byte.

TekPrevu .......... ,. ·· o .J .. ....

~: lOOmV @: -lOOmV

6. 78ms S. 38ms

~: ¡: ::¡lt·:: 8~2 :.-uª~ : • 1 • • •

• 1 • • • ------ ···- .. . .. . : -! By1e:1 ByteJ : Byte5 By187 _Byte9

. . . . .

. ; . · ' ·. ¡.

Ch l i S.00 V 0.00 V

4 Oct 2004 11 •~J2.os11ooms 1s:J1:02

Figura 4.2.3. 1 Ejemplo de mensaje enviado del AVR al transmisor

Finalizando el envió del último bit, el microcontrolador espera un tiempo suficiente para permitir que el transmisor termine de enviar la trama antes de responder a la computadora con el carácter que funge de acknowledge.

- 14 -

Dicha consideración se tomó para establecer un control de flujo de información, puesto que a pesar de que el microcontrolador puede recibir una gran cantidad de datos y redirigirlos, el transmisor no estaría listo para procesarlos si estos se presentan en una ráfaga mayor a l O bytes cada 0.138 segundos (limitación impuesta por el algoritmo de codificación del transmisor). Este proceso se detalla en el algoritmo de la figura 4.2.3.2.

Limpiar puerto

Á 1

Incrementar index

Á

Si

INICIO

" Inicialización de perifértcos

(UART,puertos)

" char rxBuffeff]; int index;

intbrtlndex; command;

temp;

" lndex = O

" index < 10

.- (se procesaron todos los bytes?)

No

" command = rxBuffe,tindexJ (obtener byte a procesar)

" billndex = O

" bitlndex < 8

Notificar a PC de operación finalizada

Á

1

Retardo para que el Si .- transmisor finalize el envio

de datos

( se enviaron todos los brts?)

N Extraer bit a enviar al . o.-

transmisor (lsb de command)

" ; Colocar bit y reloj en alto en el puerto

• Mantener reloj en alto 40 us:

" Colocar brt y reloj en bajo en el puerto

" · Mantener reloj en bajo 40 us

" Hacer corrimiento a la derecha de ¡ command para obtener siguiente

bit a enviar

" Incrementar bitlndex

Figura 4.2.3.2 Algoritmo usado por el AVR para envió de datos al transmisor

- 15 -

A fin de mostrar los resultados de dicha implementación en el presente trabajo, se definió un conjunto de referencias de velocidad en el programa descrito en el apartado 4.2.1, enviándolas posteriormente al transmisor.

Los datos definidos para dicha prueba se muestran en la tabla 4.2.3. 1:

Referencia Referencia

(binario msb ... lsb) Byte 1 1 00000001 Byte 2 -1 10000001 Byte 3 85 01010101 Byte 4 -85 11010101 Byte 5 42 00101010 Byte 6 -42 10101010 Byte 7 101 01100101 Byte 8 -101 11100101 Byte 9 127 01111111

Byte 10 -127 11111111

Tabla 4.2.3.1 Referencias enviadas a transmisor

Las señales generadas por el A VR para transmitir los datos al transmisor correspondientes a las referencias antes mencionadas, se muestran en las figuras 4.2.3.3 a 4.2.3.7. En dichas imágenes obtenidas con el osciloscopio, el canal 1 corresponde a la señal de reloj y el canal 2 muestra los bits enviados.

Tek Prevu M2.ooms

~ íl . '] !\ -1 90 V ·i.to: -1. 70 V

Tiempodebit--1\: 8-1.0µs <:ro: 1 19ms

f" ! F ! : ! ""'!' ! f'. : F"!"'!'4 ~ "! !""!""~

~

j a

.. fi ...

·~:.,,.lI·-::~·-· .. -J.! .... ·-::-·-·-:_.·, • .... ! . ~ .

Chl 5.00 V Z 200µs A Chl J 0.00 V

4 Oct 2004 :, - -676.000µs 18:38:23

Figura 4.2.3.3 Envío de los bytes 1 (1) y 2(- 1) del AVR al transmisor

- 16 -

Dado que teóricamente se requieren 80 µs para transmitir un bit, y se envían 1 O bytes de información, el proceso de comunicación del A VR al transmisor debe durar 6.4 ms. Sin embargo, de la figura 4.2.3.2 se observa que el tiempo de bit puede variar ligeramente (en dicho caso el valor es de 84 µs ), con lo que el tiempo de transmisión real(6.78 ms) es superior al teórico en aproximadamente un 12 por ciento, como se muestra en la figura 4.2.3.1.

Sin embargo dicha diferencia no constituye ningún problema en la operación del sistema, dado que el receptor acepta los datos con el flanco de subida del reloj y comienza la transmisión hasta que cuenta con los l O bytes.

4.3 Proceso de decodificación de trama RF

Dado que uno los objetivos del presente proyecto consiste en migrar las funciones de los tres microcontroladores del prototipo anterior [2] al DSP 56F8323, en el rubro de comunicaciones resultó necesario el diseño e implementación de un algoritmo de decodificación de trama a fin de sustituir al microcontrolador PIC l 6F67 6.

Antes de describir el algoritmo empleado, resulta conveniente mencionar las principales características observadas de la señal recibida. En principio la trama demodulada contiene un delimitador de inicio formado por ocho pulsos (preámbulo), donde el tiempo en alto y en bajo de cada pulso debería encontrarse muy próximo a 400 µs ( al menos a los 416 µs [2]). Sin embargo en realidad la duración del pulso en alto en esta sección es muy variable oscilando entre 450 µs hasta casi 800 µs, observándose un valor típico de 480 µs. Ejemplos de estas señales se pueden observar en las figuras 4.3.1, para un pulso típico, y 4.3.2 para un pulso de duración prolongada .

Pres Pr

: i

i &,· '

í!il) 2.00 V "

P 20.oms

Z 1.00ms A (I,~ f 4.20 V

13 Nov 2004 o~· -J.04000ms 12:48:56

Figura 4.3.1 Pulso de preámbulo con duración en alto de 480 us (valor típico)

- 17 -

Pres Pr

L ,

riII) 2.00 V •,.

P20.0ms ó: 40.0mV

5.04 V 11111 :. llil ~ 620µs

:tt: 4.92ms

ll.OOms A i,:f 4.201'

u-·· -2.70000ms 11 Nov 2004 12:47: 18

Figura 4.3.2 Pulso de preámbulo con duración en alto de 620 us

En tanto, la duración en bajo se mantiene prácticamente constante en alrededor de 280 µs, como se observa en la figura 4.3.3. Así, la duración de un pulso de preámbulo oscila entre 730 µs hasta l 080 µs.

Pres Pr P 20.0ms

D

D

ll.OOms A l;_f 4.201'

•••• -3.04000ms

0.00 V 5.04 V

280µs tt: 4.64ms

13 Nov 2004 12:48:21

figura 4.3.3 Duración típica en bajo de los pulsos de preámbulo

El preámbulo constituye la sección más crítica para decodificar, puesto que se debe discernir entre el ruido y una señal válida. Además, el carácter "aleatorio" de los pulsos en dicha sección obliga a implementar un esquema flexible.

Luego del preámbulo se encuentra un tiempo en bajo llamado encabezado, en teoría dicho encabezado debería ser de 4 ms; pero, en realidad tiene una duración de alrededor de 4.2 ms, como se muestra en la figura 4.3.4.

- 18 -

Deten.

[!DJ 2.00 V "-•

P20.0ms

-, . - r: --- , -~. · ' ~-~- - "'"' --l~ . .

--- -,-= ,-r . ·-- ... ·- ·=. ,...~ __ , ... -·-

l2.00ms A tl1cf 4.20V

4.96 V 120mV

4.20ms 50.8ms

13 \Jov 2004 ü-+• 54.6SOOms 12:57:01

Figura 4.3.4 Tiempo típico de duración de encabezado

La última sección de la trama corresponde a los bits de los datos de velocidad y un byte extra para checksum. En esta parte, la señal sufre variaciones mínimas en comparación del preámbulo. Una característica importante de la señal observada es que a los 600 µs de iniciada la sección correspondiente a la codificación de un bit, se encuentra el valor que le corresponde.

Otra consideración de relevancia, radica en que el ruido presenta características de impulso y de pulso, esto significa que puede darse una transición muy rápida de niveles o bien que la señal generada por el ruido puede permanecer en alto por varios microsegundos.

A partir de las consideraciones anteriores se definió como lo más conveniente y eficiente establecer un esquema de codificación basado en muestreo y temporización acotada por intervalos.

Para dicho propósito se decidió emplear únicamente un temporizador y una línea de entrada del DSP de manera coordinada. La línea de entrada que recibe la información del receptor (definida en la tabla 6.2.2.1) está configurada para atender interrupciones externas, así con cada flanco de subida ejecutará parte del algoritmo (ilustrada en la figura 4.3.1 ) al detectar el inicio de alguno de los componentes de la trama (pulsos de preámbulo o bits de datos) o ruido.

El temporizador tiene la función de cuantificar el tiempo entre un evento y otro, así como la notificación de un intervalo vencido (lo cual indicaría que no llegó alguno de los elementos de la trama en el límite establecido) mediante la generación de una interrupción, el funcionamiento detallado de este elemento se describe en la figura 4.3.3.

- 19 -

De manera general, el algoritmo se divide en tres secciones, una para detección de preámbulo, otra para detección de encabezado y la de obtención de datos.

Para detectar el preámbulo se emplea un periodo de muestreo de 220 µs, donde se requiere que en dos o tres muestras consecutivas exista un nivel alto, garantizando un intervalo desde 440 µs hasta casi 880µs . Posteriormente se toma una o dos muestras extra donde se requiere que exista un nivel en bajo. Con esto se valida la llegada de un pulso de preámbulo y se continúa dicho proceso hasta detectar los ocho pulsos.

Dado que para un pulso sólo debe existir un evento de interrupción, correspondiente al inicio del mismo, la generación de otro evento en la entrada durante el proceso de muestreo implica que la señal que se comenzó a procesar es ruido y que presumiblemente ha llegado una señal válida o se trataba de un pulso válido y se presentó ruido en el proceso.

Para detectar el encabezado únicamente se mide el tiempo que transcurre entre el fin del preámbulo y la siguiente transición en alto, a fin de que se encuentre en el intervalo de 3.9 ms a 4.4 ms. De presentarse un pulso antes del límite inferior no presentarse al cumplirse el tiempo definido por el límite superior se habrá presentado un error (muy probablemente ruido) o una interrupción de la comunicación.

En cuanto a la detección de los datos, se establece que con la ocurrencia de una interrupción externa después del encabezado, se realice un muestreo a los 600 µs , con lo que se obtendrá un bit de la trama. Inmediatamente después de obtenido el bit,se establece un intervalo para la llegada del siguiente, que en caso de presentarse antes de lo previsto(500 µs) o después(720 µs), corresponde a un error de transmisión. El proceso se repite hasta obtener los 11 bytes encapsulados.

- 20 -

INICIO

static cuenta;

• Guardar conteo de TimerTelecom en cuenta

Detener TimerTelecom

timerRuns

no

preamb == 8 si .- (hay ocho pulsos

de preambulo)

ERROR

" Condiciones , .,. Iniciales

"

cuenta > tlnf si .- (llegó "1" en intervalo

esperado)

ERROR

Establecer el tiempo para operación , .- de TimerTelecom a partir de ""'

time2Load '

Habilitar TimerTelecom

timerRuns = TRUE (TimerTelecom en operación)

" FIN

headerDone si ., ( encabezado

recibido?)

no

" headerDone = TRUE ( Marcar encabezado

como recibido )

't'

time2Load = T_BIT ( Preparar tiempo para ""'

muestrear bit )

si

Figura 4.3.1 Sección del algoritmo de decodificación ejecutada a partir de la interrupción externa

INICIO

" Deshabilitar TimerTelecom ;

" Establecer el tiempo para operación de TimerTelecom con T _SAMPLE_P (Preparar timer para muestrear pulsos de preambulo)

" timerRuns = headerOone = FALSE

,,, pSample = pream = bitlndex = O

" sampleZero = TRUE (Pemitir una muestra , extra en bajo para los pulsos de preambulo)

,,, FIN

Figura 4.3.2 Rutina de inicialización del algoritmo

- 21 -

INICIO

'f

time2Load = T _BIT Leer ~ de entrada y headerDone (Preambulo y

header recibidos?) si"" (llegó brta si "" guardar en byte

correspondiente

no 'f

I timerRuns Jj preamb == 8

no 'f

pSample < 2 (primeras 2

"""'stras de pulso?)

no

•

si ....

tiempo?)

sanÍpleZero· = TRUE

(Permrtir pulso ancho en baio?)

si

si

No, ERROR

... No, ERROR"" 1 ;<I

'sampleZero = FALSE (no permitir'. ~ duración excesiva en bajo)

..,. Valor en pin de entrada== 1

No, ERROR

Valor de entrada== O

pSample ==·2 . 'f no-. (Permrtir pulso - No, ERROR• 1

ancho en alto?) ·

si ., pSample == 2

(Ultima muestra de pulso?) '

SI

'f

pSample = O (Preparar condiciones para muestrear

siguiente pulso)

'f

Preamb<B (faltan pulsos de

preambulo?)

no

'f

si~

Detener TimerTelea>m time2Load = T HEADER MAX

tlnf = const. de tiempo de esp;ra min. de header

'f Establecer el tiempo para operación

de nmerTelecom a partir de tirne2Load( detección de header)

... Activar TimerTelecom

'f

timerRuns = TRUE

si ., FIN

no

timerRuns = FALSE (Preparar condiciones para

detectar error en preambulo)

.,. "" FIN -11

'f pSample++

~ ( Contabilizar muestra correcta de pulso )

brtlndex == 88 "" (Llegaron todlos los

brts?)

si

'f

'Verificar integridad de datos con

Checksum

,. Detener Timer T elecom

time2Load = T_BIT_MAX tlnl = const. con tiempo de espera min. de bit

• Establecer el tiempo pera operación de nmerTelecom a partir de time2Load

( detección error en llegada de bit)

... Activar nmerTelecom

'f

timerRuns = TRUE

" .-, FIN

'f CONDICIONES

INICIALES

'f FIN

Figura 4.3.3 Sección del algoritmo de decodfficación ejecutada por el temporizador

- 22 -

-PARTE 3 DISENO DE PROTOTIPO

Capítulo 5: Tarjeta de Potencia

5.1 Propuesta de Esquemático Anterior

En la figura 5.1 . l se puede observar el esquemático previo al desarrollo propuesto en este trabajo. En este esquema se presenta en su totalidad las partes involucradas en el control planteado en dicho desarrollo. Sin embargo, el prototipo de la tarjeta de potencia diseñada en la fase anterior del proyecto fue implementado en una tableta de baquelita perforada, conectada a través de cable UTP soldado a la misma, por fines prácticos del proyecto.

Figura 5.1.1. Diagrama Lógico Tarjeta de Potencia anterior [2]

Además el tamaño de la misma es de aproximadamente l O x l l cm pues no fueron consideradas las limitaciones físicas a las cuales se debía someter de forma que pudiese ser empotrado dentro del módulo de FIRA., sin mencionar la altura que debía tener a fin de comunicar las diferentes tarjetas.

Sin embargo, la funcionalidad de dicha etapa de potencia es la adecuada para el sistema que se ha venido planteando, por lo que los valores en los elementos pasivos y reactivos así como las conexiones entre los componentes permanecen intactas.

- 23 -

Por otro lado, el diseño lógico propuesto no contempla la integración de la 2º señal del encoder del motor así como la comunicación de las mismas con la tarjeta de control.

Así pues, el trabajo en el rediseño de la Tarjeta de Potencia se basa en principio en la incorporación de los elementos faltantes con respecto a las necesidades actuales del sistema, en la generación de la documentación apropiada para los diagramas de conexión y su futura revisión y por último las consideraciones de espacio físico a las cuales debemos someter el diseño.

5.2 Rediseño en el Esquemático

Conforme a los objetivos planteados, se rediseño primero el diagrama lógico del circuito de potencia conforme a las siguientes necesidades: (Ver figura 5.2.1)

-o 1 ,,

1 11 1

-- "

,__ -' - ~, ::,:

..L. ..... -~.___, '" ,, 11

f :: - J ,, ..... ~---..... -, ... __., ~---

~, 3 -~ __., -

':---

1

,, 1

lu-1

::!~ -

1

~ ~~~ ~ .... '" "' "' "

" - 1 ... .:::::: ~ ,,·. ........,__ -- ~ " "'· "' - - I>-- ._ .:, .... - ._

1---< ::: "' "'

r

....... r\-....:.-- •• 1 •• '" . "' "'

~

Figura 5.2.1 Esquemático de Tarjeta de Potencia

5.2.1 Incorporación del pin del 2º encoder.

Cada header de los motores comunica la lectura de los dos encoders incluidos en los mismos. Mientras que durante el proyecto anterior sólo se hizo

- 24 -

la lectura de uno a fin de obtener la velocidad del motor, es necesario hacer la lectura de ambos para resolver el problema del sentido real de giro. Por ello se reconsideró dentro del diseño la conexión de este pin de manera que sea transmitido a la tarjeta de control para su procesamiento.

5.2.2 Incorporación de circuito de fuente de 3.3 Vdc.

El circuito anterior utilizaba una sola alimentación de 5 V tanto para la etapa de potencia como hacia la de control. Sin embargo la nueva etapa de control, basada en un DSP, es alimentada con 3.3 V por lo que fue requerido incluir los elementos necesarios para generar dicha alimentación y comunicarla aprovechando el bus de comunicación, hacia la tarjeta de control.

5.2.3 Circuito de filtrado para el sensado de corriente en los motores.

A pesar de haberse planteado con anterioridad la necesidad de filtrar la señal muestreada de la corriente, en la implementación en prototipo no existían tales elementos por lo que fueron reconsiderados en el diagrama lógico de este nuevo diseño.

5.2.4 Buses de comunicación basados en header en lugar de cable plano.

Mientras que en el prototipo anterior, la comunicación con la tarjeta de potencia era realizada a través de conectores de cable plano(conectores molex), se propone un rediseño de la comunicación a través de conectores headers encontrados en ambas tarjetas sobre los cuales se comuniquen entradas y salidas hacia el DSP, así como la alimentación lógica. Este diseño además brinda soporte a la estructura física del sistema y ofrece modularidad y simpleza en las conexiones.

5.2.5 Leds Indicadores y switch de encendido.

Como cualquier sistema electrónico se incorporaron indicadores luminosos para enunciar el encendido del dispositivo, así como un switch que permite encender y apagar el sistema y de esta forma cortar el consumo de la batería, sin necesidad de tener que desconectarla.

5.3 Consideraciones Físicas

El mapa de componentes y conexiones fue generado en circuito impreso a partir del modelo lógico establecido, de manera que pudiese quedar contenido sobre una tarjeta sin cables, que fuera de fácil acceso así como de dimensiones acordes a la problemática propuesta. Las consideraciones planteadas fueron las siguientes:

- 25 -

5.3.1 Tamaño real

Como primer cambio realizado para la implementación de la tarjeta se limitó el área del diagrama a las medidas del módulo del FIRA. Para ello se retomaron las medidas de la tarjeta original de potencia de Yujin Robotics la cual es de 6.6 x 6.6 cm. Con ello aseguramos que nuestra tarjeta entre en el robot y embone correctamente en los agujeros de sujeción provistos con tal efecto en la estructura del mismo.

5.3.2 Pistas en dos capas

Una de las principales ventajas del diseño en circuito impreso, es la capacidad de incorporar pistas de conexión por ambos lados de la tarjeta y por ende acomodar los dispositivos por ambas caras. Gracias a ello podemos ampliar la densidad de componentes en la tarjeta al poder distribuir mejor los mismos de acuerdo a las necesidades de diseño, de tal forma que podemos acomodar más elementos en el mismo sector pero en diferentes vistas de la tarjeta.

Debido a la naturaleza analógica de las señales que viajan en esta tarjeta no consideramos incorporar elementos de montaje superficial, pues estos suelen ser indicados para una menor potencia, por lo que se diseño para componentes de consumo normal. exceptuando el led de encendido que es de montaje superficial ya que no participa directamente con el sensado y control de los motores.

5.3.3 Comunicación

La comunicación de datos y alimentación con la tarjeta superior se diseño a través de paredes de headers hembra de 12 pines en doble fila sobre los cuales se transmiten tanto entradas como salidas y alimentación hacia el DSP. Dichas paredes brindan además, sujeción y soporte mecánico a las tarjetas. Sin necesidad de comunicar con cable plano, se depura la vista que se tiene del dispositivo y simplifica su manipulación. La separación que queda entre las tarjetas debido a los headers encontrados, se ajusta a las dimensiones de altura previstas para el diseño (18 mm aproximadamente) de forma que se integre dentro de la carcasa superior del FIRA.

5.4 Tierra Analógica Un punto importante a tratar con respecto al diseño en tarjetas de circuito impreso, es el ruido eléctrico generado en la etapa analógica por elementos de potencia que podrían hacer mella en los demás dispositivos electrónicos. Las señales analógicas son propensas a generar demasiado ruido debido a una deficiente referencia al punto de tierra del sistema. Dicho punto, conocido como la tierra analógica deber ser tal que actúe como el nodo central de una topología de conexión en estrella, donde su centro sea de un área considerablemente mayor a la de sus pistas. Además el conectar

- 26 -

dispositivos de alta disipación de calor a las zonas de tierra, permite que estas actúen como disipadores de calor naturales en la tarjeta, sin necesidad de incorporar más elementos.

Por dichas razones, se planteó el diseño de tal forma que se tuviese un polígono de tamaño considerable en el dibujo de las pistas considerado como el nodo de tierra, en el cual las diversas referencias a la misma llegaban en forma de una estrella con los vértices en los dispositivos indicados. Con ello disminuimos la posible degradación en la señal debido a referencias demasiado lejanas a la misma. Los elementos que pudieron aprovechar de la disipación natural en al zona fueron tanto los reguladores de voltaje, así como I puente H de alimentación a los motores.

5.5 Diseño del Circuito Impreso

En la figura 5.5.1, se muestra el diseño de la tarjeta de Potencia. Esta tarjeta fue generada tomando en cuenta una distribución multicapa de los elementos así como sus pistas. Las medidas y distancias relativas en las paredes de headers (ver 5.3.3) con respecto a los orificios para su anclaje, fueron considerados en relación directa a la sucesiva conexión que deberá respetar con la tarjeta de control.

Además en la figura 5.5.2 se muestran ambas caras de la tarjeta tal como fueron implementadas así como una vista previa en tercera dimensión de la tarjeta en la figura 5.5.3.

Figura 5.5.1. PCB de la Tarjeta de Potencia

- 27 -

~,

E E ~

'T o \[)

Figura 5.5.2a. Cara superior Tarjeta de Potencia

---------<mm) f>O .:;::,,:,..---------

- 28 -

-¡:,

o Q/

Figura 5.5.2b. Cara inferior Tarjeta de Potencia

Figura 5.5.3. Dibujo 30 de la Tarjeta de Potencia

- 29 -

Capítulo 6: Tarieta de Control

6. 1 Propuesta de Esquemático Anterior

Este diseño fue completamente descartado pues basaba su funcionamiento en dos microcontroladores A VR sincronizados; mismos que realizaban las funciones de sensado y control respectivamente. El prototipo no era aceptable debido a la deficiencia en la detección del sentido real así como el bajo poder computacional que pudiese ofrecer en una tarjeta considerablemente grande con respecto al módulo FIRA.

6.2 Rediseño en el Esquemático

6.2.1 Edición de bibliotecas

Se editó el símbolo lógico del DSP 56F8323 de Motorola, pues este no se encontraba en las bibliotecas del software de edición. El modelo se realizó conforme a los nombres de los pines y funciones agrupados de acuerdo a su relación lógica más que la distribución real de los mismos .

. ... p::=:::::.-vvv~--,...-,.....-......-1

Figura 6.2.1 Esquema de la Tarjeta de Control

- 30 -

6.2.2 Designación de pines

A partir del análisis de los pines y funciones que presenta el DSP, así como las necesidades de nuestro diseño, se asignaron los pines de comunicación con la tarjeta de control en relación directa a los buses de comunicación. Dicha asignación se hizo primero a partir de la conveniencia física de su disposición, con respecto al bus para evitar al máximo pistas innecesarias en la tarjeta.

Las entradas asignadas se distribuyeron de acuerdo a la Tabla 6.2.2.1:

Señal Pin Nombre Dato serializado del módulo RF 18 ISAl Corriente Motor Izquierdo 26 ANAO Corriente Motor Derecho 30 ANA4 Encoder 1 Motor Derecho 49 HOMEO Encoder 2 Motor Derecho 49 HOMEO Encoder 2 Motor Izquierdo 49 HOMEO Encoder 1 Motor Izquierdo 49 HOMEO Tabla 6.2.2.1 Pines de Entrada

X X ,_ a: o M z 1 z

1 en ~· ¡:;; ~ O _

TCO

RESET

PWMAO

PWMA1

Vc.,,3

Voo_,o

PWMA2

PWMA3

PWMA4

PWMA5

Vss IRQA

FAULTAO

FAULTA1

FAULTA2

ISAO

uuce<z::1/)aa:::uoo t-t-UU>>t->t-t-

Moto rola

56F8323

Header RF Derecho Derecho Izquierdo Izquierdo Izquierdo Izquierdo

33

o w :::;: o I

Voo_,o

XTAL

EXTAL

OCR_DIS

Vss

Vc,.,,4

VooA_OSC_PLL

VooA_AOC

VREFH

VsSA._ADC

VREFLO

VREFP

VREF'-410

VREFN

TEMP_SENSE

ANA7

Figura 6.2.2.1 Vista Superior del 56F8323 encapsulado LQPF (1]

- 31 -

En la Tabla 6.2.2.2, se pueden apreciar los pines habilitados para la programación del DSP. Dicha programación se realiza en modo serial por ser un modo fácil de implementar y cuyo uso no será extenuante mas que para programar una sola vez. La programación se realiza a partir del "boot loader" precargado en la memoria de los DSP de Freescale Motorola que será tratada con mayor detalle en el Capítulo 8.

Señal Pin Nombre Header PROG 1 21 sso PROG PROG2 22 MISO PROG Tabla 6.2.2.2. Pines de Programación

A fin de poder etiquetar cada módulo de FIRA sin necesidad de personalizar el código de su DSP, se habilitó un sector de entradas que leyera de la tarjeta el código de O a 7 asignado a la unidad manualmente con Jumpers de conexión. En la Tabla 6.2.2.3 se puede observar la asignación para tales pines.

Señal Pin Nombre Header IDO 61 CAN_RX DIP SWITCH 101 62 CAN_TX DIP SWITCH 102 63 TC3 DIP SWITCH Tabla 6.2.2.3. Pines de Etiquetado

Por otro lado, se buscó generar seis salidas que alimentan al circuito de potencia. De éstas, dos señales contienen la secuencia en PWM que controlan la velocidad del motor; mientras que con las otras 4 se determinan direcciones en el motor. La tabla 6.2.2.4, muestra las salidas asignadas en los pines del DSP.

Señal Pin Nombre Header PWM Motor Derecho 3 PWMAO IZQUIERDO PWM Motor Izquierdo 4 PWMAl IZQUIERDO Dir 2 Motor Izquierdo 13 FAULTAO DERECHO Dir 1 Motor Izquierdo 14 FAULTAl DERECHO Dir 2 Motor Derecho 15 FAULTA2 DERECHO Dir 1 Motor Derecho 16 ISAO DERECHO Tabla 6.2.2.4. Pines de Salidas

6.3 Consideraciones Físicas

El componente principal a tratar durante el diseño de la Tarjeta de Control, es el DSP, el cual es un encapsulado de 1 cm2 con 16 pines en cada costado con una separación de 0.5 mm entre cada uno. Dicho componente es de montaje superficial, es decir, no atraviesa la tarjeta por lo que sus pistas van por la misma cara en la que se encuentra.

- 32 -

Por ello los elementos de configuración, como resistencias y capacitares así como la comunicación con la tarjeta de Potencia deben ser colocados en la misma cara, además de tener dimensiones acordes al DSP. Convenientemente, se tomó la cara superior para ser la que llevara la mayor densidad de componentes pues resultaría natural a la comunicación con la Tarjeta de Potencia, pues ésta se comunica por headers con orientación inferior, por lo que sus conexiones se realizan por la cara superior. Con ello, se simplifica el modelo al requerir en la menor cantidad posible "through-holes" u orificios bilaterales, que complican la fabricación del mismo.

Así, la tarjeta fue diseñada a partir de vistas de componentes de contacto superficial, mismos que fueron adquiridos y medidos de antemano para ser asignados dentro del diseño de forma precisa.

La mayor parte de estos componentes miden aproximadamente 5 mm, por lo que en la mayoría de los casos el nivel de integración en la tarjeta permitiría de sobra colocar los elementos necesarios en el espacio asignado, pero a un costo de implementación elevado, debido a la dificultad de soldar tales elementos.

Otra consideración física consistió en el tamaño asignado para la tarjeta, la cual, no sólo debía embonar con los headers provistos en la tarjeta de potencia, sino que debía de ser de un tamaño menor. De esta forma se permite, por un lado, el acceso al switch de inicio del sistema, y por el otro a colocar los elementos de mayor altura como capacitares de la tarjeta de potencia sin necesidad de entrar debajo de la tarjeta de control.

Por ultimo se debió limitar el espacio al cual se tenía acceso debido a la necesidad de comunicación con la Tarjeta Receptor de RF, cuya peineta es horizontal y de 12 pines, por lo que su conexión al diseño resulta por demás compleja, ya que es necesario mantenerla acostada de forma tal que se ajuste dentro de la altura del FIRA.

6.4 Tierra Digital

El tratamiento a la referencia de masa o tierra en el área digital del diseño es tan importante como en la etapa analógica pero bajo un concepto ligeramente diferente. Para ello, se colocaron las diferentes referencias a tierra en lugares convenientes al diseño por proximidad de nodos. para después asignar un área sobre la tarjeta de diferentes nodos que, dependiendo si no hubiese pistas en dicho lugar, colocaba nodos de tierra repartidos sobre ambas caras de la tarjeta.

Mientras en la cara superior dichos nodos no fueron sustancialmente grandes, en la cara inferior se definieron áreas que recubrían toda la superficie, ya que la mayor parte de los componentes se encuentran en la

- 33 -

cara superior. Ello le permite al sistema dos cosas importantes. por un lado aumentar el campo de referencia al que se tiene acceso y por el otro actúa como un blindaje natural de la electrónica digital contra las posibles interferencias tanto eléctricas como electromagnéticas que se generasen debajo de ésta. Así podemos considerar se mantiene aislada tanto nuestra etapa de control así como nuestra tarjeta de telecomunicaciones, potencial víctima del ruido.

6.5 Diseño de las pistas

En la medida de lo posible los elementos fueron colocados lo más cercano a sus respectivas conexiones, de manera que la cantidad de orificios bilaterales, fuera menor. Con ello, la mayor parte de las pistas hacia el DSP, se ven como buses que se fragmentan cerca del elemento al que van asignados. Además, los elementos de configuración, se mantienen cercanos y alineados a sus referencias permitiendo conectar con una sola línea varios componentes.

6.6 Conexión con módulo de RF

La complejidad que se deriva del módulo RF parte del hecho de su conector paralelo. De haber contado con la tarjeta en perpendicular con su conector, hubiese bastado con colocar un header hembra que lo alojara y conectar los pines de interés.

Sería complicado debido a la integración en la tarjeta de RF. sustituir su conector por uno diferente. por lo que se opto a adaptarlo al diseño. Analizando la tarjeta notamos que de los 12 pines que requiere para ser anclada, sólo 3 son funcionales; esto es, que los 9 restantes cumplen una función de sujeción mecánica solamente.

Así. se consideró discriminable el torque que pudiese generar el peso de la tarjeta sobre la conexión y así optar por sólo ofrecer conectividad a tales pines, los cuales se pueden notar en la tabla 6.6.1

PIN Función 1 GND 2 vcc 3 No tiene 4 Dato Serial

5-12 No tiene Tabla 6.6.1 Pines Hábiles de la tarjeta RF

Así. se colocó un header sobre la tarjeta de control de forma que 12.2 mm del cuerpo de la tarjeta de RF se encimase sobre la tarjeta de control, conectándose sólo por 4 pines.

- 34 -

Para poder conectarlo de forma vertical se ideó una interfaz basada en un header hembra y un conector a 90º soldados de forma que permitiesen la conexión con la tarjeta antes mencionada. Dicha solución no es contraproducente al diseño que se había realizado, pues conserva la modularidad entre los sistemas así como su facilidad en el manejo; además a pesar de no ser un elemento discreto, resulta fácil de construir.

En la figura 6.6.1 se muestra el diseño propuesto. Este embona adecuadamente con su contraparte de Tarjeta de Potencia por lo que la modularidad y simplicidad en el sistema es total.

En las siguientes figuras (6.6.2 6.6.3), se muestran las vistas de las caras de la tarjeta, así como una vista en tercera dimensión de cómo podría quedar en la implementación.

E u

N . ....

tE-~~~~~~~~2560 <m1l)~~~~~~~~~

6.5 cm

Figura 6.6.1. PCB de la Tarjeta de Control

- 35 -

"' E E

.......

....... o . N V-

• 00 00 00 00 00 00 00 00 00 00 00 00

• o

Figura 6.6.2a. Cara superior de la Tarjeta de Control

• 00 00 "' 00 3

3 00 '-"

00 OI ...... 00 -o 00 . 00

V) -V

00 00 00 00

(mm) ~s.:o .e

Figura 6.6.2b. Cara inferior de la Tarjeta de Control

- 36 -

Figura 6.6.3a. Vista 30 Cara superior de la Tarjeta de Control

Figura 6.6.3b. Vista 30 Cara inferior de la Tarjeta de Control

- 37 -

PARTE 4: IMPLEMENTACIÓN

Capítulo 7: Implementación de la Tarjeta de Potencia

7.1 Circuito Impreso

El circuito fue plasmado mediante serigrafía en tarjetas de fibra de vidrio por ambas caras y perforadas de acuerdo a las guías de grosor especificadas en el PCB. Cada hoyo bilateral (through hole) fue implementado usando trozos de alambre soldados entre ambos puntos. En la figura 7 .1 . 1 se puede apreciar una foto de dicha tarjeta.

Figura 7.1.1 Tarjeta de Control Vista Superior e Inferior

7.2 Inclusión de componentes

La Tarjeta de Potencia contiene básicamente dos fuentes de alimentación, una de 5 V y una de 3.3 V respectivamente así como el puente H antes mencionado para alimentar los motores. Ya que la distribución en la tarjeta fue diseñada a partir del espacio físico necesario para cada elemento, la integración resultó natural. La mayor parte de los elementos son de conexión bilateral, esto es atraviesan la tarjeta para su montaje, por lo que soldarlos resultó sencillo en su mayoría. En la figura 7.2.1 se puede apreciar como quedo conectado el sistema.

- 38 -

Figura 7.2.lb Vista inferior

7.3 Pruebas

Se probó el sistema con una pila de 7.4 V recargable que alimenta todo el sistema y se simularon las entradas digitales al puente H provenientes del DSP conectando los motores en sus respectivos headers. Los motores giran en ambas direcciones bajo la lógica propuesta así como conmutan su velocidad a razón de la señal en PWM que es provista a los mismos. Así mismo, el tren de pulsos variable en frecuencia de los encoders es sensado correctamente así como la señal de corriente demandada. Cabe destacar que dichas señales son alimentadas a los headers de comunicación para que el DSP pueda hacer tanto el control de corriente como el de velocidad.

Es importante mencionar además que debido a la distribución del nodo de tierra como un disipador natural de calor, el calentamiento en los elementos como el puente H no es tan significativo permitiéndoles trabajar con un mejor desempeño en un mayor rango de acción.

- 39 -

Capítulo 8: Implementación de la Tarjeta de Control

8.1 Circuito Impreso

De igual forma, las tarjetas fueron fabricadas sobre fibra de vidrio serigrafiando ambos lados de la misma. Sin embargo, el detalle tan fino que debían guardar las pistas, principalmente las que comunican al DSP, quedo falto de precisión en ciertos sectores de la tarjeta prototipo, por lo que se requirió revisar y eliminar cortos indeseables entre las pistas del DSP y otros elementos. La tarjeta puede ser vista en la figura 8. 1 . 1

Figura 8.1.1 a Tarjeta de Control Vista Superior

Figura 8.1.1 b Tarjeta de Control Vista Inferior

- 40 -

8.2 Montaje de Elementos

Se decidió montar primero todos los elementos en la tarjeta dejando el DSP al último, para evitar un sobrecalentamiento del mismo al colocar los otros dispositivos. Tales componentes fueron obtenidos previamente al diseño y medidos para conocer las necesidades físicas en la tarjeta así como obtener la mejor distribución. Como se mencionó con anterioridad, los componentes utilizados son de montaje superficial y básicamente representan el conjunto de capacitares útiles para la configuración interna, así como elementos de despliegue como leds y resistencias de pull-up en los pines seleccionados.

En la figura 8.2.1 se puede apreciar la tarjeta previo al montaje del DSP.

Figura 8.2.1 Tarjeta de Control (sin DSP)

8.3 Montaje del DSP

No obstante los grandes beneficios que ofrece el uso de elementos como este DSP al tener un mayor poder de cálculo para los algoritmos requeridos, es importante recalcar la dificultad de montarlo directamente sobre una tarjeta de circuito impreso. Al término del montaje algunos pines fueron deshabilitados (sin conexión a la tarjeta) para evitar posibles corto circuito entre los mismos y de nueva cuenta se separaron los cortos que pudiesen haber sido generados al momento de soldar.

Figura 8.3.1 Tarjeta de Control con DSP (FRENTE)

- 41 -

Figura 8.3.2 a I b Tarjeta de Control (con DSP) Vista Superior y Acercamiento

- 42 -

A continuación se muestra como quedan montadas ambas tarjetas sobre el módulo del robot FIRA/Mirosot

Figura 8.3.3 a I b I e Tarjetas Potencia y Control Montadas

- 43 -

Y con la incorporación de la tarjeta receptora de RF

Figura 8.3.4 a I b I c Tarjeta de Telecomunicaciones Incorporada

- 44 -

8.4 Programación del DSP

Como se indicó anteriormente en el capítulo 3 los DSP de Motorola cuentan con un programa precargado de fábrica conocido como Bootloader que a través de una comunicación serial desde la computadora y usando un programa de propietario; también llamado Bootloader, permite descargar el código del programa tanto en memoria de programa como de datos para posteriormente arrancar la aplicación recién incorporada en el DSP.

A partir de la interfase de programación armada se estableció comunicación con el DSP tal como se indica en [10]. Sin embargo, la comunicac1on no era siempre la adecuada por lo que el índice de programación se veía seriamente afectado especialmente con códigos de mayor tamaño. Al analizar la configuración montada para el DSP se notó que la línea de alimentación al DSP estaba severamente distorsionada debido a una Inductancia que de acuerdo con Motorola serviría para filtrar la línea analógica. Esta situación redundaba en una pobre referencia de alimentación al circuito tanque que controla al PLL interno del DSP propiciando que se generaran oscilaciones irregulares en el reloj interno y por lo tanto no pudiese establecer la sincronía en la comunicación requerida. Al sustituir el elemento antes referido por su modelo equivalente en estado permanente, se mejoró considerablemente la señal de alimentación, con lo que la programación del DSP se da de forma inmediata y sin errores.

Por otro lado, la configuración original del Bootloader en el DSP funciona de tal forma que la primera instrucción que ejecuta es una interrupción al sistema en espera de la señal de programación desde su puerto SCI. Dicha espera es dada en la parte alta de un registro de 16 bits en la dirección Oxl FFD, conocido como BOOT_START_DELAY, cuyo valor por defecto es de 255. Este valor le indica al DSP quedar ciclado en una espera infinita por la instrucción de programación. Es por ello que al hacer un reset por hardware en el mismo, no arranca la aplicación antes programada y es necesario reprogramar el mismo, esto es, no se borra el programa grabado sino que el Bootloader bloquea su ejecución.

Obviamente no resulta útil tener que reprogramar el DSP cada vez que arranque el robot, sin embargo está dado de esta forma para permitir un chequeo del programa prototipo. Para poder modificar tal configuración fue necesario entrar al ProcessorExpert del CodeWarrior dentro de CPU en las opciones de construcción (Build Options, Figura 8.4. l). Dentro se puede encontrar la opción de soporte al "Serial Bootloader" que por defecto no existe. Al habilitarlo se debe cambiar además el valor de Boot_Delay menor a 255, cuidando no asignar un valor de O ya que éste le refiere al DSP no esperar por la reprogramación serial y saltar directamente a la aplicación. De programar el DSP con un O en la espera, se perdería la posibilidad de reprogramarlo a través de tal interfase, la cual es la única físicamente implementada en la Tarjeta de Control.

- 45 -

IIIITnt-, l [. :.tnJil(iM~AM _:_] ~ lj '-~ \. ,. ~

fje-c i l.d0,4,r! T~íJ", Pl<as:<rE~ i :fe, ecn.,..,.wuc

(:!,üpe,..-.¡$,¡­

:::'=> (/>"·

,' . l ----•P-~

:tJ~ ílM"n

(;:,[oo,:,-i­

' (:!, f'ESL

1• ~ _,OSPCC<,q¡io • f'ESL >Wl' ro 2 " Udirdol-: Onehardoilor,1 2 a.u ... ......., " u,..~.--.1lllr'1...,I d " u ... codei..mPE1smvt111 d • US<1code<ft"f'Erl""'Jlo<i d a ...;.. .. liola '* ,.J .2 • .i:ol-,IW,I ro _2 .- ~ _,., .2

r..,..i.., .. r..QíM -· rtf I; -s.-...,.., 2--------------, e.o, u, dd9J H,

I

~ -- ·--·-·'.-:'..:.. • S,,d ""' V.."W

.- Hq,2 0100 3 -IIOII/IIMl-l 3~ 8 -11011/IWIA,. " N- P.1~1

!l n..11-1v1Ho,s tti,- r"1mfyrr,rv~n~. ,rt., ~.- tt~-..;,, !!a Pfflo!'S «urol to~ 1.M1°'S G)i(.at»"1 . .!!J _,..-.¡,fc,tl><t"'1:~cnO!o.:'ñ ili -- ----- - - --

Mte<i o .!!l " <¡.,. "' .!!! • Owlóer ffwl .!J

Figura 8.4.1 Edición del BOOT_START_DELA Y

De seguir tales indicaciones, al encender el sistema el Bootloader entra en una rutina de espera por la señal de programación; si al cabo del tiempo definido ésta no es recibida, pasa la ejecución a la memoria de aplicación. Por defecto consideramos adecuado para ésta aplicación cambiar el tiempo por 5 seg.

8.5 Consideraciones de la Implementación

Al realizar las pruebas con el sistema completo, esto es motores, tarjeta de potencia, tarjeta de control, tarjeta de comunicaciones y pila; se observó que el arranque del mismo demanda demasiada corriente durante el estado transitorio, lo que afecta el voltaje que el regulador puede llegar a generar, dando valores alrededor del 75% del valor de alimentación esperado.

Al parecer, tal consumo se debe a que la tarjeta de comunicaciones debe ser preferentemente alimentada con 5 V, sin embargo funciona correctamente con 3.3 V, aunque a una mayor demanda de corriente, especialmente al inicio.

Se notó que al desconectar la tarjeta de comunicaciones del sistema y arrancar éste, la alimentación es plena y ya estando en el estado permanente se puede conectar la tarjeta sin alteraciones en la línea. Ya que el tener que montar y desmontar la tarjeta no sería la situación más práctica, demeritando además la funcionalidad del sistema, se optó por incorporar de forma emergente un 2º switch habilitador de la tarjeta de comunicaciones, aprovechando el módulo de expansión de SPI. Para tal efecto fueron cortadas las pistas de este módulo de su conexión con el DSP, y así evitar posibles problemas durante la programación.

-46 -

El proceso normal de encendido quedo entonces activando el Switch de Encendido General en la tarjeta de potencia (de arriba hacia abajo) y posteriormente el Swtich de Telecomunicaciones en la tarjeta de control (de derecha a izquierda). (Figura 8.5.1)

Figura 8.5.1 Proceso de Encendido

- 47 -

Capítulo 9: Conclusiones v Perspectivas

9.1 Conclusiones

Se diseñaron e implementaron bajo las restricciones físicas de la planta mecánica del robot, sistemas modulares en ta~etas de circuito impreso que dividen tanto física como funcionalmente los bloques base del sistema, esto es, bloque de control, bloque de comunicaciones y bloque de potencia.

La interacción entre los subsistemas se realiza de forma natural sin mayor participación de un operador mas que en el anclaje de las tarjetas, identificación del módulo y encendido del mismo.

El sistema de alimentación utiliza actualmente una pila de 7.4 Volts que brinda la potencia suficiente al robot, sin embargo el diseño permitiría una batería de mayor voltaje y suministro de corriente, a fin de funcionar con una sola carga durante mayor tiempo. El sistema redujo su consumo de potencia y el área de trabajo ya que se evolucionó el diseño a un solo DSP de 1 Omm2

de bajo consumo contra los dos AVR's de 80x15mm alimentados por 5V más un PIC que hacia interfaz con la tarjeta de telecomunicaciones.

Como se comentó durante el reporte, la integración del DSP en las tarjetas es el punto más delicado de la implementación pues no se cuenta con las herramientas de montaje necesarias para una colocación propia. Sin embargo el sistema puede ser manufacturado en sitios especializados con lo cual aseguremos un correcto montaje y por ende funcionalidad del mismo, situación que causa la mayor problemática al realizar un prototipo de tal índole.

Asimismo, se pudo reestablecer la capacidad de comunicación por radiofrecuencia y control del robot desde la computadora mediante el software desarrollado y el módulo de comunicaciones implementado. Gracias al algoritmo de decodificación diseñado, se pueden obtener tasas de recepción prácticamente del 100%, bajo condiciones adecuadas del entorno. Aun en las peores condiciones se puede garantizar que los datos recibidos (después de procesados por el algoritmo) no contienen error alguno.

Gracias al sistema logrado, la tasa de muestreo en los algoritmos de control bajó considerablemente de 3 ms al orden 0.5 µs, menos de 0.016 % del tiempo original. Con esto se resuelve la mayor problemática generado por el lazo de corriente ya que, debido a la dinámica eléctrica, era necesario que el muestreo fuera más rápido sin estar limitado por el procesamiento interno

- 48 -

de las señales. Dicho procesamiento se realiza en pocos ciclos de reloj debido a la naturaleza de ejecución paralela en el DSP.

Por último, el sistema es programable in situ, objetivo muy importante pues permite comunicarse con el DSP de forma serial a través de la interfase diseñada con tal propósito. Además se brinda la posibilidad de uso del SPI del DSP que permitiría en cierto momento aumentar las capacidades tanto en memoria como en comunicación.

9 .2 Perspectivas y Trabajo a Futuro

A partir de los resultados obtenidos, se puede pensar en la integración del primer equipo de robots Fira/Mirosot basados en la arquitectura que se desarrolló en el presente proyecto, dado que ya se ha logrado subsanar las deficiencias presentes en el sistema original, en torno a control y comunicaciones.

Por otra parte, dado que el sistema electrónico del robot ha sido completamente sustituido, cabe proponer que también se desarrolle el sistema mecánico en proyectos futuros, a fin de contar con un sistema totalmente desarrollado en el Tecnológico de Monterrey.

Aún cuando el sistema de telecomunicaciones opera satisfactoriamente, puede ser mejorado de manera sustancial al incrementar la tasa de transmisión, dado que la actual es bastante limitada. Al contar con el DSP para recepción de la información, puede plantearse la posibilidad de implementar algún esquema de compresión de datos.

Asimismo, en el presente proyecto se empleó la interfase RS232 para la implementación del módulo de comunicaciones y programación; pero puede pensarse en migrar de nuevo a un esquema basado en USB. En dicho caso, se propone que el software desarrollado para comunicación con el dispositivo se fundamente en bibliotecas de enlace dinámico [DLLs) a fin de mantener dichos componentes como entidades reutilizables, y permitir su empleo ya sea por aplicaciones desarrolladas en lenguaje C. C++ o Java [mediante el uso de JNI)

Dado que el esquema de programación empleado fue el basado en SCI, puede mejorarse el módulo de programación a fin de incorporar un bloque de JTAG que permita emplear el entorno de desarrollo CodeWarrior a fin de depurar la operación del DSP y contar con un método adicional de programación. Dicha mejora implica modificar ligeramente la tarjeta de control, de modo que los pines necesarios sean accesibles mediante un conector.

-49 -

En torno al desarrollo del sistema de inteligencia de juego, se considera que ya es factible comenzar con el desarrollo de tal componente del sistema, así como también se puede evaluar la posibilidad de iniciar los trabajos alrededor del sistema de percepción.

En el área de control, se pueden implementar y probar nuevos algoritmos de mayor complejidad como puede ser el de Dinámica Inversa debido al aumento de poder de cálculo en el mismo y características antes discutidas que brindan la posibilidad de aumentar las variables sensadas así como disminución dramática en los tiempos de muestreo, permitiendo una respuesta rápida y precisa en el jugador. Cabe destacar que un algoritmo de tal naturaleza requiere de tener acceso a mucha memoria entre más complejo sea el modelo mecánico embebido, sin embargo, debido a que la planta del robot es de dos coordenadas generalizadas y la matriz de inercia es invariable al tiempo, los recursos con los que cuenta el sistema actualmente bastarían para tal implementación.

Sintetizando la esencia de este proyecto que representa la culminación de una serie de esfuerzos orientados a desarrollar un sistema que superara al original, puede pensarse en propuestas aún más avanzadas a fin de establecer un esquema novedoso que proporcione ventajas a nivel de competencia y evolución tecnológica.

Una de dichas propuestas consiste en sustituir los motores de CD por actuadores de CA. Con dicho cambio se lograría un sistema más eficiente a nivel energético, con mayores prestaciones mecánicas. Sin embargo dicha idea, conlleva la aplicación de nuevas estrategias de control (por ejemplo control vectorial) con el rediseño de los sistemas de potencia y control.

Por otro lado, se ha demostrado con este proyecto la posibilidad latente de implementar sistemas desarrollados enteramente en el Tec de Monterrey basados en DSP para ser integrados en los diferentes proyectos de Robótica y Sistemas Digitales que se puedan desarrollar. Ello implica que se puede pensar en incorporar los diferentes algoritmos ideados en tarjetas de desarrollo a sistemas reales que se puedan acoplar, como es el caso del control en la caja de aviónica del Helicóptero, procesamiento para el SCARA y demás aplicaciones que surjan bajo la base de requisitos computacionales elevados a un bajo costo y alta escala de integración.

- 50 -

Capítulo 1 O: Referencias

[1] Información comercial y de desarrollo del DSP en

http://www.freescale.com

[2] BLANCAS.R,RAÑA.M .. Proyectos de Ingeniería IEC. ITESM CCM, México

DF 2004

[3] TENA.C,TORRECILLA.E. Proyectos de lngenieía carrera /SE. ITESM CCM.

México D.F. 2003.

[4] Datos Técnicos del DSP del Manual Preliminary Technical Data 56F8323

16-bit Hybrid Controller.

[5] Hoja de datos del microcontrolador AT90S8535

[6] Guía de Desarrollo para equipo de Telecomunicaciones en rfPic

Development Kit 1 Quick Start Guide

[7] Página de la Asociación FIRA

http://www.firo.net/soccer/simurosot/overview.html

[8] Hoja de datos del microcontrolador AT90S2313

[9] Página oficial de la tecnología Java

http://iava.sun.com

[10] Manual del Bootloader de Motorola SCI/CAN

- 51 -

Anexos en el CD 1. Documentos

a. Versión electrónica del Reporte Escrito

b. Presentación Final

2. Manuales en PDF

a. Manual de Arranque del DSP

b. Manual de Referencia del DSP

c. Programación por Bootloader

d. Manual de Periféricos del DSP

e. Hojas de datos componentes varios

i. DSP 56F8323

ii. Microcontrolador AT90S2313

iii. Acondicionador de niveles MAX232

iv. Puente H L298

v. Regulador de voltaje conmutado LM2575

vi. Regulador de voltaje de 3.3 volts

3. Imágenes

a. Fotos de la Implementación Anterior

b. Fotos del proceso de Implementación

c. Archivo con el póster del proyecto.

d. Pruebas de Fun·aonamiento en Video

4. Aplicaciones

a. Lector shareware de PDF

b. Código y proyecto para microcontrolador AVR AT90s2313 del módulo de

comunicaciones

c. Código y proyecto empleado para el DSP 56F8323 de la tarjeta de control

d. Bibliotecas Java generadas para comunicación serial.

e. Documentación del código Java desarrollado

f. Paquete javax.comm proporcionado por Sun Microsystems

g. Licencia CodeWarrior

h. Aplicaciones de programación por SCI/CAN Bootloader de Freescale.

5. Esquemas

- 52 -

a. Archivos de Protel con esquemáticos y PCBs de las tarjetas de control y

potencia.

b. Archivos de Protel con esquemático del módulo de comunicaciones y

control

c. Diagramas de bloque y algoribnos del sistema general y subsistemas de

comunicación y detección de errores.

- 53 -