universidad de castilla la mancha escuela …arco.esi.uclm.es/public/pfc/antonio.ruedas.pdfen...

UNIVERSIDAD DE CASTILLA LA MANCHA

ESCUELA SUPERIOR DE INFORMATICA

INGENIERIA

EN INFORMATICA

PROYECTO FIN DE CARRERA

“Control de robots Lego NXT basado en FPGA”

Antonio Ruedas Garcıa

Septiembre, 2014

UNIVERSIDAD DE CASTILLA LA MANCHA

ESCUELA SUPERIOR DE INFORMATICA

Departamento de Tecnologıas y Sistemas de Informacion

PROYECTO FIN DE CARRERA

“Control de robots Lego NXT basado en FPGA ”

Autor: Antonio Ruedas GarcıaDirector: Fernando Rincon Calle

Septiembre, 2014

palabra

TRIBUNAL:

Presidente:

Vocal:

Secretario:

FECHA DE DEFENSA:

CALIFICACION:

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

Copyright © 2014 Antonio Ruedas Garcıa.Se permite la copia, distribucion y/o modificacion de este documento bajo los terminos dela licencia de documentacion libre GNU, version 1.3 o cualquier version posterior publicadapor la Free Software Foundation, sin secciones invariantes. Puede consultar esta licencia enhttp://www.gnu.org.

Este documento fue realizado en LATEX.

Resumen

El kit de construccion de robots Lego NXT utiliza como elemento de control funda-mental el llamado brick, que no es mas que un sistema empotrado basado en un microproce-sador, con un sistema operativo basico, que le permite obtener informacion de los diferentessensores disponibles, y generar la senales de control a varios tipos de actuadores.

Este proyecto tiene como cometido principal la sustitucion del brick por una plata-forma de prototipado basada en FPGA, con el fin de disponer de un entorno de pruebas masflexible sin las limitaciones de la estructura fija del microcontrolador de Lego.

palabra

Agradecimientos

Muchos anos de esfuerzo y dedicacion para llegar hasta el final de una etapa que secierra con la realizacion de este proyecto.

En primer lugar, gracias a mis padres, que me lo han dado todo. Por su apoyo,comprension y animos en todo momento, por ser el ejemplo perfecto de que el trabajo duroda sus frutos.

Gracias a mi hermano, con quien tengo la suerte de compartir profesion, que tantasveces me ha ayudado a lo largo de estos anos cuando me han surgido dudas.

A mi director de proyecto, Fernando, por su inestimable ayuda, su paciencia ypor todo lo que he aprendido de el. A Juan Pablo, por su colaboracion y por la idea deloptoacoplador, y a todos los profesores que han contribuido a formarme. A los chicos dellaboratorio, en especial a Manu y a Julian, que siempre estuvieron dispuestos a echarme unamano.

Por ultimo, me gustarıa dedicar unas palabras a un ser muy especial para mı. Migata, Mishi, que durante su corta vida me lleno de felicidad y de alegrıa, y que hace pocoabandono este mundo, dejandome un vacıo y una tristeza que tardaran en irse.

Antonio

palabra

A la memoria de mi gata, Mishi.

palabra

Indice general

1. Introduccion 1

2. Antecedentes 5

2.1. Lego Mindstorms NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1. Brick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3. Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.4. Comunicacion de los sensores y actuadores . . . . . . . . . . . . . 10

2.1.5. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. BrickPi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Hardware reconfigurable . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1. FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2. Lenguajes de descripcion de hardware . . . . . . . . . . . . . . . . 15

2.4. HLS: Sıntesis de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3. Objetivos 21

3.0.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Indice general

3.0.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . 22

4. Arquitectura del sistema 23

4.1. Interfaz de los sensores y actuadores . . . . . . . . . . . . . . . . . . . . . 25

4.1.1. UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.2. Interfaz NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.3. Transmision y Recepcion NXT . . . . . . . . . . . . . . . . . . . . 29

4.2. Logica de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1. Algoritmos en hardware . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.2. Microprocesador empotrado . . . . . . . . . . . . . . . . . . . . . 31

4.2.3. Programacion remota . . . . . . . . . . . . . . . . . . . . . . . . . 33

5. Caso de uso 35

5.1. Algoritmos en hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2. Microprocesador empotrado . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3. Programacion remota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6. Metodos y fases de trabajo 47

6.1. BrickPi: Ingenierıa inversa . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2. Fases de la programacion hardware . . . . . . . . . . . . . . . . . . . . . . 48

7. Resultados y conclusiones 53

7.1. Resultados de la sıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1.1. Algoritmos en hardware . . . . . . . . . . . . . . . . . . . . . . . 54

X

Indice general

7.1.2. Microprocesador empotrado . . . . . . . . . . . . . . . . . . . . . 54

7.1.3. Programacion en remoto . . . . . . . . . . . . . . . . . . . . . . . 55

7.2. Coste del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.4. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

A. BrickPi: Protocolo de comunicacion 59

A.1. Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A.2. Transmision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A.2.1. Configuracion de los sensores . . . . . . . . . . . . . . . . . . . . 61

A.2.2. Actualizacion de los valores . . . . . . . . . . . . . . . . . . . . . 62

A.3. Recepcion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.4. Tiempos entre tramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

B. Plataforma y conexionado 65

B.1. FPGA: Virtex-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B.2. Pines de expansion de la FPGA . . . . . . . . . . . . . . . . . . . . . . . . 66

B.3. Conexion entre FPGA y BrickPi: Optoacoplador . . . . . . . . . . . . . . 69

Referencias 75

XI

Indice de figuras

1.1. Robot Lego Mindstorms NXT . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1. Sensor de luz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Sensor de sonido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3. Sensor de ultrasonidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4. Sensor de contacto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5. Sensor de colores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6. Servo motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7. Conector RJ-12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.8. BrickPi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.9. GPIO de la Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.10. Arquitectura de una FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.11. Tipos de datos con precision arbitraria en HLS . . . . . . . . . . . . . . . . 18

4.1. Arquitectura general del sistema . . . . . . . . . . . . . . . . . . . . . . . 24

4.2. Arquitectura del componente de la interfaz de los sensores y actuadores . . 25

5.1. Maqueta de una barrera de parking montada con piezas de Lego NXT . . . 36

6.1. Diagrama de flujo de la metodologıa de programacion hardware . . . . . . 51

Indice de figuras

B.1. Extracto del esquematico de la tarjeta de expansion . . . . . . . . . . . . . 67

B.2. Extracto de la guıa de referencia de la Virtex-6 . . . . . . . . . . . . . . . . 68

B.3. Esquema de un optoacoplador . . . . . . . . . . . . . . . . . . . . . . . . 69

B.4. Esquema del optoacoplador NVE IL710 . . . . . . . . . . . . . . . . . . . 70

B.5. Tabla de verdad del optoacoplador NVE IL710 . . . . . . . . . . . . . . . 71

B.6. Soldadura del circuito de los optoacopladores . . . . . . . . . . . . . . . . 71

B.7. Esquema del circuito de los optoacopladores . . . . . . . . . . . . . . . . . 72

B.8. Vista frontal del circuito de los optoacopladores . . . . . . . . . . . . . . . 73

XIV

Indice de tablas

7.1. Utilizacion del dispositivo para el metodo de algoritmos en hardware . . . . 54

7.2. Tiempos para el metodo de algoritmos en hardware . . . . . . . . . . . . . 54

7.3. Valores estimados de la sıntesis para el metodo con microprocesador empotrado 54

7.4. Utilizacion del dispositivo para el metodo con microprocesador empotrado . 54

7.5. Tiempos para el metodo con microprocesador empotrado . . . . . . . . . . 55

7.6. Valores estimados de la sıntesis para el metodo en remoto . . . . . . . . . . 55

7.7. Utilizacion del dispositivo para el metodo en remoto . . . . . . . . . . . . 55

7.8. Tiempos para el metodo en remoto . . . . . . . . . . . . . . . . . . . . . . 55

7.9. Costes desglosados del proyecto . . . . . . . . . . . . . . . . . . . . . . . 56

A.1. Tipos de mensajes del BrickPi y su identificacion numerica . . . . . . . . . 61

A.2. Valores asociados a cada tipo de sensor . . . . . . . . . . . . . . . . . . . 62

1 Introduccion

Lego Mindstorms NXT [leg]1.1 es un kit de construccion de robots programablesusado frecuentemente para fines didacticos. Este kit de construccion de robots utiliza comoelemento de control fundamental el llamado brick, que no es mas que un sistema empotra-do basado en un microprocesador, con un sistema operativo basico, que le permite obtenerinformacion de los diferentes sensores disponibles, y generar la senales de control a variostipos de actuadores.

Figura 1.1: Robot Lego Mindstorms NXT

Los diferentes sensores y actuadores se conectan al brick mediante un conector

1. Introduccion

modular de 6 posiciones que sirve tanto de interfaz analogica como digital. La interfaz digitalpuede comunicarse mediante I2C y RS-485.

El brick de Lego cumple perfectamente su funcion como plataforma de experimen-tacion en software, aunque utilizarlo supone estar sujetos a las limitaciones de rendimientoy a la estructura fija del microcontrolador. Por este motivo, serıa razonable pensar en unaalternativa que permitiese aprovechar las posibilidades del kit de robots mediante la cons-truccion de un entorno mas flexible que el ofrecido por el brick de Lego para el prototipadoy el desarrollo de algoritmos nativos en hardware sobre robots moviles Lego.

Implementando las interfaces de estos sensores y actuadores, podrıa ser posiblesustituir el brick de Lego por una plataforma de prototipado basada en FPGA (Field Pro-

grammable Gate Array) con el ya mencionado objetivo de disponer de un entorno de pruebasmas flexible. Las FPGA son los dispositivos logicos reconfigurables mas utilizados hoy endıa; contienen bloques de logica reconfigurable (CLB) cuya interconexion y funcionalidadse pueden programar.

Esta plataforma plantearıa un rango de posibilidades mucho mas ancho y flexibleque el del brick, pudiendo realizar algoritmos mas complejos implementados directamente enhardware que permitiesen ejecutar aplicaciones que requieran un alto nivel de computacioncomo, por ejemplo, el reconocimiento de imagenes. Podrıan crearse tambien sistemas entiempo real, algo que en el brick de Lego serıa irrealizable.

Ademas, se plantea que dicha plataforma se pueda utilizar a tres niveles:

Implementacion de los algoritmos directamente en hardware.

Programacion software mediante la utilizacion de un microprocesador software empo-trado en la FPGA.

Envıo de ordenes e implementacion de algoritmos utilizando la interfaz de forma re-mota y comunicandose con la plataforma mediante el puerto serie.

Al contrario que el brick, que solo permite comunicacion hacia el exterior me-diante Bluetooth, la plataforma podrıa adaptarse de manera sencilla a cualquier protocolode comunicacion existente (como Bluetooth, Zigbee, 802.15, etc.) conectando el adaptadorpertinente.

2

En definitiva, se pretende construir una plataforma para el prototipado de algo-ritmos en robots Lego que permita realizarlo de diversas formas, ya sea: en hardware, ensoftware, mixto, desde el exterior comunicandose con diversos protocolos, etc.

Uno de los grandes desafıos que se presentan es la descodificacion de las senalesque se mandan a los actuadores y se reciben de los sensores. Por fortuna, existe un disposi-tivo que realiza precisamente esto: BrickPi [Dexd]. Este aparato consta de dos microcontro-ladores Arduino, y es capaz de controlar los actuadores y leer los sensores del Lego NXT.Esta disenado en concreto para ser conectado a una Raspberry Pi mediante un puerto serie,sin embargo, serıa posible conectarlo tambien a una FPGA. Gracias al BrickPi, se logra unaabstraccion de las interfaces analogicas, lo que permite evitar la tarea de la ingenierıa inversade las senales y de profundizar en el campo de la electronica.

A pesar de no ser ya necesario, puede resultar de interes mencionar que esta in-genierıa inversa del protocolo de las senales esta resuelta por Martin Schoeberl [Mar] y sepuede consultar.

Uno de los inconvenientes de la programacion hardware es su mayor complejidadfrente a la programacion software al tener que implementar los algoritmos en lenguajes dedescripcion de hardware (HDL), gestionando la logica de la FPGA: recursos, transferenciasentre registros, etc. Para mitigar esto, existen herramientas de sıntesis, como Vivado HLS yOpenCL SDK, que permiten generar una implementacion para FPGA a partir de un lenguajede alto nivel, a esto se le conoce como sıntesis de alto nivel (HLS). Por ejemplo, en Viva-do HLS, el algoritmo se disena en C, C++ o SystemC depurandose dentro del entorno dedesarrollo para posteriormente sintetizar el codigo del algoritmo generando el equivalente enHDL.

Se pretende, por tanto, hacer uso de la sıntesis de alto nivel para la produccion de lamayor parte del codigo del proyecto, exceptuando aquellas partes en las que, por limitacionesde uso (no todo puede ser descrito mediante HLS), no sea posible.

3

2 Antecedentes

Indice2.1. Lego Mindstorms NXT . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1. Brick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3. Actuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.4. Comunicacion de los sensores y actuadores . . . . . . . . . . . . 10

2.1.5. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2. BrickPi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.2. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3. Hardware reconfigurable . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.1. FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.2. Lenguajes de descripcion de hardware . . . . . . . . . . . . . . . 15

2.4. HLS: Sıntesis de alto nivel . . . . . . . . . . . . . . . . . . . . . . . . 16

2. Antecedentes

2.1. Lego Mindstorms NXT

Lego Mindstorms NXT es la segunda generacion de la serie de robots Lego Minds-torms creados por LEGO en colaboracion con el Instituto Tecnologico de Massachussetts(MIT por las iniciales de su nombre en ingles, Massachussetts Institute of Technology). Elkit de construccion esta formado por actuadores, sensores, las diferentes piezas de construc-cion, una baterıa y el llamado brick, un microcontrolador programable.

2.1.1. Brick

El cerebro del Lego Mindstorms NXT, conocido como brick es un modulo basadoen un microcontrolador que ofrece diversos puertos de entrada y salida. El brick tiene lassiguientes caracterısticas:

Microcontrolador ARM7 de 32 bits con 256 KB de memoria flash y 64 KB de memoriaRAM.

Microcontrolador AVR de 8 bits con 4 KB de memoria flash y 512 bytes de RAM.

Pantalla LCD de 100x64 pıxeles.

Cuatro puertos de entrada.

Tres puertos de salida.

Puerto USB.

Bluetooth 2.0.

Altavoz de 8 kHz, 8 bits de resolucion y tasa de muestro de 2 a 16 kHz.

Baterıa de litio recargable.

6


2.1.2. Sensores

Sensor de luz Permite tomar una muestra de luz mediante un bloque modificado con unconductor electrico en un extremo y una camara oscura que capta las luces en el otro extremo.

Figura 2.1: Sensor de luz

Sensor de sonido Es capaz de expresar la medida tanto en decibelios (dB) como en de-cibelios con ajuste A (dBA). En la medicion de decibelios con ajuste A, la sensibilidad delsensor esta ponderada por la del oıdo humano, es decir, son los sonidos que puede escucharuna persona. En la medicion de decibelios estandar, todos los sonidos se miden con la mismasensibilidad.

Figura 2.2: Sensor de sonido

Sensor de ultrasonidos Permite al robot detectar objetos enviando pulsos de ultrasonidode 40 kHz y midiendo el tiempo que tarda en viajar, reflejarse y volver. Este sensor es capazde detectar objetos que se encuentren desde 0 a 255 cm.

7

2. Antecedentes

Figura 2.3: Sensor de ultrasonidos

Sensor de contacto El sensor de contacto es el mas simple de todos pues solo distingueentre dos posiciones: pulsado (1) y no pulsado (0).

Figura 2.4: Sensor de contacto

Sensor de colores Detecta seis colores diferentes: azul, verde, rojo, amarillo, blanco ynegro. Es la evolucion del sensor de luz.

Figura 2.5: Sensor de colores

Sensor de giro Giroscopo de un solo eje que detecta la rotacion y devuelve la velocidadde rotacion en grados por segundo.

8


Sensor de temperatura Permite leer el valor aproximado de la temperatura mediante lainteraccion de un termistor en uno de los extremos que genera un campo magnetico permi-tiendo la deteccion aproximada de la temperatura del bloque que lo contiene.

Otros sensores Existen multitud de sensores mas como: brujula, acelerometro, de rotacion,RFID, etc.

2.1.3. Actuadores

Los unicos actuadores del robot son:

Servo motor: cuenta con un sensor de rotacion que le permite calcular la velocidad yla distancia.

Figura 2.6: Servo motor

LED: el sensor de colores usa un LED que puede brillar rojo, verde o azul y lo usapara medir los niveles de luz reflejada.

9

2. Antecedentes

2.1.4. Comunicacion de los sensores y actuadores

Para la comunicacion de informacion de los sensores y actuadores del robot, seutiliza un cable de 6 hilos con conectores similares al RJ-12 estandar. Se diferencia de el enla colocacion de la pestana de enganche, que se encuentra situada a la derecha. En la Figura2.7 se muestra el esquema de los hilos del conductor.

Figura 2.7: Conector RJ-12

A continuacion, se detalla la funcion de cada uno de los hilos del conector [Gas07]:

Pin blanco: AN Puede usarse como entrada analogica, la senal se conecta a un convertidoranalogico-digital de 10 bits. En estos sensores se suministra una tension constante durante 3ms y lee la entrada durante 0.1 ms, repitiendo el ciclo indefinidamente. La frecuencia de laslecturas del sensor es de 333 Hz con una corriente aproximada de 18 mA.

Pines negro y rojo: GND Son pines de tierra y estan conectados entre sı dentro del brick

y en los sensores.

Pin verde: IPOWERA Proporciona la corriente necesaria a los sensores y a los encodersde los motores. Se conecta internamente a los siete puertos de entrada y salida del brick y

10


tiene un lımite de corriente de 180 mA.

Pines amarillo y azul: DIGIAI0 y DIGIAI1 Son los pines de entrada y salida utilizadospara el protocolo de comunicacion digital I2C.

2.1.5. Software

Existen diferentes entornos y lenguajes de programacion para el diseno de softwarede control de los robots. El brick cuenta con un firmware que es una implementacion deuna maquina virtual, por lo que el software que se desarrolle ha de ser compatible con lamisma, aunque existen alternativas que utilizan un firmware personalizado. A continuacion,se describen algunos de los entornos y lenguajes que se pueden utilizar para la programacionde los NXT.

NXT-G NXT-G es el software oficial proporcionado por LEGO que permite programar elNXT, actualizar el firmware, controlarlo por medio de bluetooth, etc.

Esta basado en la programacion grafica de LabVIEW que consiste en un entornointeractivo en el cual se arrastran bloques que permiten programar el robot de manera senci-lla. Cada bloque representa una funcion, por ejemplo, controlar el movimiento de un motoro recibir la informacion medida por un sensor.

Es intuitivo y facil de usar al estar especıficamente disenado para programar losNXT, por lo que cualquier persona sin conocimientos de informatica podrıa manejarlo.

LabVIEW Toolkit Como se explico previamente, NXT-G se basa en LabVIEW, que uti-liza programacion grafica de flujo de datos. Para permitir una programacion mas avanzada,National Instruments, la empresa desarrolladora de LabVIEW, lanzo un Toolkit para losNXT.

Next Byte Codes Fue el primer lenguaje de programacion textual para los NXT y esta ba-sado en lenguaje ensamblador. Utiliza el firmware por defecto del brick.

11

2. Antecedentes

Not eXactly C Es un lenguaje de alto nivel parecido a C basado en Next Byte Codes.

Lego::NXT Proporciona una API para la programacion de los NXT en Perl [REFEREN-CIA: https://metacpan.org/pod/LEGO::NXT].

lejOS NXJ Es una maquina virtual Java que reemplaza al firmware del brick permitiendola programacion de robots en Java.

Otros lenguajes Existen muchos otros firmwares personalizados y librerıas en otros len-guajes como Python, C++, Ada, Ruby, MATLAB y un largo etcetera.

2.2. BrickPi

BrickPi es una placa de reducido tamano (ver Figura 2.8) que actua de interfaz delos sensores y actuadores del Lego Mindstorms NXT para conectarlos a una Raspberry Pisustituyendo de esa manera al brick de LEGO.

Pueden conectarse hasta cuatro motores NXT y hasta cinco sensores digitales oanalogicos.

2.2.1. Hardware

Las caracterısticas hardware del BrickPi son:

Dos microcontroladores ATmega328 basados en Arduino.

Reloj con una frecuencia de 16 MHz.

Alimentacion de 9 a 12 V.

Los motores se controlan mediante dos circuitos Texas Instruments SN754410 [Tex].

Los sensores pueden ser tanto analogicos como digitales y son leıdos por el microcon-trolador Arduino.

12

2.2. BrickPi

Figura 2.8: BrickPi

Los puertos de los sensores y los motores son enchufes hembra para los conectores delNXT [Dexb].

El BrickPi se conecta a la Raspberry Pi mediante los pines de entrada/salida deproposito general (GPIO) de esta ultima, que sirve precisamente para conectar perifericos ytarjetas de expansion (como el BrickPi). Se comunica mediante una UART usando los pinesTXD y RXD (de transmision y recepcion, respectivamente) que se pueden ver en la Figura2.9.

2.2.2. Firmware

El BrickPi recibe ordenes y peticiones por parte de la Raspberry Pi mediante unaUART por un puerto serie actuando el BrickPi como esclavo. El firmware del BrickPi [Dexc]se descarga mediante los pines ISP (InSystem Programming) a cada ATmega328 desde laRaspberry Pi. El firmware se ejecuta constantemente en un bucle actualizando los valores

13

2. Antecedentes

Figura 2.9: GPIO de la Raspberry Pi

del motor, los valores de encoder, los valores de los LED y los valores de los sensores. Estebucle es interrumpido por llamadas del puerto serie provenientes de la Raspberry Pi paraactualizar los motores y recibir informacion de los sensores.

2.3. Hardware reconfigurable

La flexibilidad de los procesadores de proposito general, que son capaces de ejecu-tar cualquier tipo de tarea, tiene como contrapartida la falta de paralelismo en su ejecucion,produciendo un rendimiento menor. Los procesadores especıficos, sin embargo, son capaces

14

2.3. Hardware reconfigurable

de obtener un gran rendimiento por estar optimizados para una tarea en concreto, pero conel inconveniente de que no pueden ser utilizados para otros propositos.

Lo ideal serıa disponer de un dispositivo que contase con lo mejor de los procesa-dores de proposito general y lo mejor de los procesadores especıficos, es decir, flexibilidad yrendimiento. Estas caracterısticas las encontramos en los dispositivos logicos programables,PLD (Programmable Logic Device).

Los dispositivos logicos programables mas usados actualmente son las FPGA (delingles Field Programmable Gate Array).

2.3.1. FPGA

Una FPGA es un dispositivo semiconductor formado por bloques de logica pro-gramable, CLB (Configurable Logic Block), cuya interconexion y funcionalidad puede serconfigurada o programada in situ mediante un lenguaje de descripcion de hardware, HDL(Hardware Description Language).

Los CLB se encuentran organizados en filas y columnas en la FPGA unidos entresı mediante elementos de interconexion. La enorme libertad disponible en la interconexionde dichos bloques confiere a las FPGA una gran flexibilidad. Tambien existen pequenoselementos en cada una de las patillas del chip que definen la forma en que este trabajara:entrada, salida, entrada-salida. En la Figura 2.10 se puede ver un esquema de la arquitecturade una FPGA con los elementos previamente nombrados.

2.3.2. Lenguajes de descripcion de hardware

Un lenguaje de descripcion de hardware (HDL, Hardware Description Language)es un lenguaje de programacion especializado que se utiliza para definir la estructura, disenoy operacion de circuitos electronicos analogicos o digitales. Estos lenguajes posibilitan ladescripcion formal de un circuito electronico, su analisis automatico y su simulacion. Hoyen dıa existen herramientas suficientemente maduras para sintetizar cualquier descripcionen un HDL realizada a nivel de transferencia de registros directamente a hardware, ademas,muchos sistemas hardware se abordan todavıa a este nivel de abstraccion.

15

2. Antecedentes

Figura 2.10: Arquitectura de una FPGA

Los lenguajes de descripcion de hardware mas extendidos son:

VHDL (VHSIC Hardware Description Language)

Verilog

SystemC

ABEL (Advanced Boolean Expression Language):

2.4. HLS: Sıntesis de alto nivel

La sıntesis de alto nivel consiste en describir mediante lenguajes de alto nivel (talescomo C, C++ y SystemC) algoritmos o comportamientos que se pretenden implementar enun circuito electronico.

Funciona como una capa de abstraccion que permite reducir la complejidad de laprogramacion hardware evitando utilizar los HDL clasicos. Ademas, el proceso de verifica-cion del diseno es tambien mas sencillo porque se realiza directamente sobre el software.

16


Esto va a permitir que se generen disenos hardware de una forma mas rapida y sencilla, au-mentando de esta forma la eficiencia de los disenadores, siendo la herramienta de sıntesis dealto nivel la encargada de generar la implementacion RTL (Register-transfer level). RTL esuna abstraccion usada en los HDL para crear representaciones de alto nivel de un circuito.

La HLS realiza dos tipos distintos de sıntesis sobre el diseno:

Sıntesis de los algoritmos: Toma el contenido de las funciones y lo sintetiza en RTLen un determinado numero de ciclos de reloj.

Sıntesis de las interfaces: Transforma los argumentos o parametros de las funciones enpuertos RTL permitiendo la comunicacion con otros disenos del sistema. La sıntesisde las interfaces tambien afecta a las variables globales y a los valores de retorno.Los tipos de interfaces son: cable, registro, bus, FIFO, RAM... Ademas, se sintetizantambien senales de control de cuando una operacion puede comenzar o cuando se hacompletado; las FIFO son un claro ejemplo de esto, pues son necesarias senales parasaber si se puede leer de ella o no.

Los efectos de la sıntesis de las interfaces condiciona lo que se puede sintetizaren la de los algoritmos y viceversa. Hay un gran numero de posibles implementaciones yoptimizaciones, y por lo tanto, un amplio espacio de posibles soluciones; y la sıntesis dealto nivel abstrae al usuario de estos detalles permitiendole aumentar su productividad yrealizar el diseno en el menor tiempo posible, seleccionando la solucion mas adecuada paralas caracterısticas especıficas del circuito.

La sıntesis de alto nivel se realiza en varios pasos. A continuacion se describenalgunos de estos pasos y conceptos fundamentales de la HLS.

Extraccion del control y de la ruta de datos El control se extrae de los bucles y condi-ciones presentes en el codigo. Cada vez que una funcion entra o sale de un bucle, supone elequivalente a entrar o salir de un estado en una maquina de estados finitos RTL.

La ruta de datos se extrae haciendo un desenrollamiento de los bucles y evaluandolas condiciones logicas del diseno. En las fases posteriores se haran optimizaciones sobre laruta de datos.

17

2. Antecedentes

Planificacion La fase de planificacion se encarga de determinar en que ciclo se producecada operacion. Se tienen en cuenta la frecuencia y fluctuacion del reloj, la informacion detiempos del dispositivo y la latencia de las directivas. La HLS genera la implementacion masoptima basandose en las restricciones de tecnologıa y del usuario y en las directivas especifi-cadas por el usuario. Por ejemplo, un mismo codigo podrıa implementarse de varias manerasdistintas: gastando mas ciclos de reloj pero utilizando menos sumadores y multiplicadores,y viceversa.

Binding La fase de binding determina que recursos hardware (sumadores, multiplicadores,etc.) se utilizaran para cada operacion planificada. Las decisiones de binding influyen en laplanificacion de operaciones, por lo que se consideran durante la fase de planificacion.

Tipos de datos con precision arbitraria En C, los tipos de datos son de un ancho de 8,16, 32 o 64 bits, sin embargo, las operaciones RTL soportan anchos arbitrarios.

La HLS necesita un mecanismo para especificar anchos de bit arbitrarios ya que encaso contrario, puede darse el caso de que el diseno RTL utilice, por ejemplo, multiplicadoresde 32 bits cuando los necesite solo de 17 bits.

HLS soporta los siguientes tipos de datos (enteros o de punto fijo) de precisionarbitraria:

Figura 2.11: Tipos de datos con precision arbitraria en HLS

Funciones y jerarquıa RTL Cada funcion del codigo se traduce a un bloque RTL. Esnecesario que exista una funcion principal, llamada top, que llame al resto. Es posible hacerinlining de una funcion anadiendo una directiva, o puede hacerlo de manera automatica si lafuncion es muy pequena.

18


Los argumentos de la funcion top conforman los puertos de entrada y salida delnivel superior.

Restricciones de diseno HLS tiene un conjunto de restricciones que pueden ser usadas porel usuario y que pueden hacer, entre otras cosas:

Especificar la latencia entre funciones, bucles y regiones.

Especificar el lımite de recursos usados.

Sobrescribir las dependencias implıcitas permitiendo cambiar el orden en el que seproducen las operaciones.

19

3 Objetivos

Indice3.0.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.0.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . 22

3.0.1. Objetivo general

Como ya se expuso previamente, el objetivo de este proyecto consiste en la cons-truccion de un entorno mas flexible que el del brick del Lego para el prototipado y desarrollode aplicaciones sobre robots moviles Lego NXT, implementando en hardware una parte, otoda, la logica de control del robot, y haciendo uso de una FPGA como plataforma de proto-tipado. Ademas, se utilizara tambien un BrickPi para la abstraccion de las interfaces de lossensores y actuadores del robot.

El sistema tendra una arquitectura modular, es decir, se compondra de varias capaso modulos que se comunicaran entre ellos.

3. Objetivos

3.0.2. Objetivos especıficos

Realizacion la ingenierıa inversa del protocolo que utiliza BrickPi para comunicarsecon los sensores y actuadores del robot.

Implementacion de una UART para la comunicacion serie entre la FPGA y el BrickPi.

Conexion fısica de los dispositivos utilizados.

Programacion de las interfaces de transmision y de recepcion.

Programacion de una interfaz general para la programacion del robot en la que seutilicen directamente los valores de los sensores y actuadores.

Utilizacion de la interfaz para controlar al robot mediante tres metodos distintos:

• Conexion de la interfaz con un microprocesador software integrado en la FPGAmediante un bus intermedio que actua como middleware para permitir la progra-macion en software de algoritmos de control para el robot.

• Conexion de la interfaz con el exterior mediante una comunicacion cableada(puerto serie, Ethernet) o inalambrica (Bluetooth, Zigbee) para permitir el controlremoto del robot.

• Programacion directamente en hardware de los algoritmos de control del robot.

Programacion de demostradores de comportamiento del robot haciendo uso de algunode los tres metodos anteriores.

Utilizacion de sıntesis de alto nivel para la mayor parte de la programacion hardware,obviando aquellas partes en las que, por restricciones de la HLS, no sea posible, y que,por consiguiente, se programaran directamente en HDL.

22

4 Arquitectura del sistema

Indice4.1. Interfaz de los sensores y actuadores . . . . . . . . . . . . . . . . . . . 25

4.1.1. UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.2. Interfaz NXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.3. Transmision y Recepcion NXT . . . . . . . . . . . . . . . . . . . 29

4.2. Logica de control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1. Algoritmos en hardware . . . . . . . . . . . . . . . . . . . . . . 30

4.2.2. Microprocesador empotrado . . . . . . . . . . . . . . . . . . . . 31

4.2.3. Programacion remota . . . . . . . . . . . . . . . . . . . . . . . . 33

La arquitectura del sistema esta formada por un conjunto de bloques o moduloshardware distribuidos por capas o niveles que se conectan entre sı:

Interfaz de los sensores y actuadores: Contiene los drivers de los sensores y actuadoresy provee la interfaz para los mismos.

Middleware: Capa intermedia para la comunicacion entre la interfaz y el resto de com-ponentes.

Logica de control: Contiene la logica de control del robot, se pretende resolver de tresmaneras diferentes:

4. Arquitectura del sistema

• Hardware: Se codifican los algoritmos de control en C sintetizable y se conectanmanualmente a la interfaz VHDL. El proyecto necesita se resintetizado, pero serealiza ıntegramente en hardware.

• Microprocesador empotrado: Se utiliza un microprocesador soft core empotradoen la FPGA llamado MicroBlaze. Se conecta mediante el middleware a la capa dela interfaz. Los algoritmos de control se programan en software con un lenguajede alto nivel (C) y se ejecutan en el microprocesador.

• Remotamente: Se hace uso de la interfaz de forma remota enviando y recibiendodatos a traves del puerto serie conectado a la FPGA. Los algoritmos se puedencodificar en cualquier lenguaje de programacion que permita la comunicacioncon el puerto serie.

Figura 4.1: Arquitectura general del sistema

24

4.1. Interfaz de los sensores y actuadores


Constituye el componente mas importante del sistema. Es el encargado de estable-cer la comunicacion con el BrickPi formando ası una interfaz para controlar los actuadoresy recibir la informacion de los sensores.

Figura 4.2: Arquitectura del componente de la interfaz de los sensores y actuadores

Se describe en una entidad VHDL que tiene como componentes un reloj generadoa partir de la herramienta de generacion de cores Coregen [Xilc] (parte de la suite para elbackend sobre las FPGA de Xilinx) y los descritos a continuacion.

4.1.1. UART

La conexion con el BrickPi se realiza mediante una comunicacion en serie duplex,ya que ambos extremos cumplen funciones de transmisor y receptor. Para establecer estaconexion es necesario el uso de una UART.

Una UART (Universal Asynchronous Receiver-Transmitter, Transmisor-ReceptorAsıncrono Universal en castellano), es un controlador de la interfaz serie que toma bytes dedatos y los transmite bit a bit de manera secuencial, anadiendo al principio un bit de inicio y alfinal un bit de paridad (opcional) y un bit de parada. Gracias a estos bits de control, la UARTreceptora puede ensamblar cada byte correctamente. La velocidad a la que se transmite cadabit depende del baud rate o tasa de baudios, que es el numero de unidades de senal que setransmiten por segundo.

25


En un principio, se intento implementar la UART en C sintetizable, pero debido aproblemas de sincronizacion entre la parte de recepcion y la de transmision a causa de limi-taciones de la sıntesis de alto nivel, sobre todo a la hora de modular procesos concurrentes,se opto por implementarla directamente en VHDL.

El componente UART esta modelado a partir de dos maquinas de estados, que con-trolan la transmision y la recepcion de los bytes de datos. Estas gestionan las senales decontrol de un registro de desplazamiento, que es el recurso utilizado para realizar el proce-so de traduccion serie/paralelo. Ademas, incluye un contador de baudios que genera un ticcuando dicho contador llega a un determinado numero que se calcula teniendo en cuenta latasa de baudios y la frecuencia del reloj. Ası, por cada tic generado, se sabe cuando se ha derecibir o transmitir un bit.

El contador de tics para este caso, teniendo en cuenta que la FPGA tiene una fre-cuencia de reloj de 125 MHz y el BrickPi trabaja con una tasa de baudios de 500000 bps, esde 250:

1

125MHz= 0,000000008 s (4.1)

1

500000 bps= 0,000002 s (4.2)

0,000002 s

0,000000008 s= 250 (4.3)

La UART tiene tambien dos componentes de memoria, dos colas FIFO generadascon Coregen, que se utilizan para almacenar los datos que van a ser transmitidos y los datosque son recibidos. Los datos se reciben a traves de la entrada Rx del componente, con anchode un bit, y se transmiten a traves de la salida Tx, con ancho tambien de un bit.

La entidad VHDL de la UART queda de la siguiente forma:

1 entity uart_axi is2

3 generic (

4 C_BAUD_CNT : natural := 250);

5 port (

6 clk : in std_logic;

7 reset : in std_logic;

8

9 rx : in std_logic;

10 tx : out std_logic;

11

26


12 -- rx interface

13 s_axis_tvalid : IN STD_LOGIC;

14 s_axis_tready : OUT STD_LOGIC;

15 s_axis_tdata : IN STD_LOGIC_VECTOR(7 DOWNTO 0);

16

17 -- tx interface

18 m_axis_tvalid : OUT STD_LOGIC;

19 m_axis_tready : IN STD_LOGIC;

20 m_axis_tdata : OUT STD_LOGIC_VECTOR(7 DOWNTO 0));

21 end uart_axi;

Las senales Rx y Tx son las que van a parar al brick, mientras que las demas secorresponden con la interfaz de los drivers. En este ultimo caso, se trata en realidad de sendasFIFOs, cada grupo de tres senales controla una de ellas. Estas tres senales se correspondencon el bus de datos, una senal que indica la disponibilidad de un nuevo dato (tvalid), y otrapara que el receptor del dato indique si esta listo para ello (tready).

4.1.2. Interfaz NXT

Es un componente escrito en C sintetizable que tiene como entrada los parametrosde velocidad y habilitacion de los motores, y el tipo de los sensores, y como salida el valorde los encoders de los motores y el valor de los sensores.

Implementa el protocolo de BrickPi, que se puede consultar en el Anexo A, eje-cutandose de forma constante enviando las ordenes de los motores y recibiendo la informa-cion de los sensores. Para evitar problemas de desincronizacion, la transmision y la recepcionse ejecutan de forma secuencial, una detras de otra.

Tiene dos FIFOs para la trasmision y para la recepcion, que se corresponden conuna estructura de tipo hls::stream en el codigo C sintetizable. Estas estructuras actuan comoobjetos que implementan operaciones de tipo read()/write(), y que la herramienta VivadoHLS es capaz de reconocer como operaciones sobre las FIFO. Por lo tanto, desde el puntode vista del programador del componente, practicamente todo se reduce a leer y escribir deforma conveniente sobre las estructruras de tipo hls::stream. Como los datos se escriben yse reciben byte a byte, las FIFO tienen un ancho de 8 bits.

Los anchos de bits de las entradas y salidas de la interfaz son:

27


Velocidad de los motores: short, 16 bits.

habilitacion de los motores: unsigned char, 8 bits.

Encoders de los motores: int, 32 bits.

Valores de los sensores: short, 16 bits.

Tipos de los sensores: unsigned char, 8 bits.

La interfaz de la funcion top del componente en C sintetizable queda de la siguienteforma:

1 void nxt_iface(hls::stream<unsigned char> &nxt_tx, hls::stream<

unsigned char> &nxt_rx, short m1_speed, short m2_speed, shortm3_speed, short m4_speed, unsigned char m1_enable, unsigned charm2_enable, unsigned char m3_enable, unsigned char m4_enable,

int* encoder1, int* encoder2, int* encoder3, int* encoder4,

short* sensor1, short* sensor2, short* sensor3, short* sensor4,

unsigned char sensor_type_1, unsigned char sensor_type_2,

unsigned char sensor_type_3, unsigned char sensor_type_4, int*waiting);

Los dos primeros parametros se corresponden con las interfaces de los drivers,siendo sendas FIFOs, una de transmision y otra de recepcion. El resto de parametros secorresponden con las senales que sirven para asignar valores a los actuadores y que recibenla informacion de estado de los sensores. Por ejemplo, para activar el motor 1, serıa tansencillo como poner el parametro m1 enable a 1 en el codigo C.

Mientras que la entidad VHDL resultante de transformar el codigo C es:

1 entity nxt_iface is2 port (

3 ap_clk : IN STD_LOGIC;

4 ap_rst : IN STD_LOGIC;

5 nxt_tx_V_din : OUT STD_LOGIC_VECTOR (7 downto 0);

6 nxt_tx_V_full_n : IN STD_LOGIC;

7 nxt_tx_V_write : OUT STD_LOGIC;

8 nxt_rx_V_dout : IN STD_LOGIC_VECTOR (7 downto 0);

9 nxt_rx_V_empty_n : IN STD_LOGIC;

10 nxt_rx_V_read : OUT STD_LOGIC;

11 m1_speed : IN STD_LOGIC_VECTOR (15 downto 0);




28


15 m1_enable : IN STD_LOGIC_VECTOR (7 downto 0);




19 encoder1 : OUT STD_LOGIC_VECTOR (31 downto 0);




23 sensor1 : OUT STD_LOGIC_VECTOR (15 downto 0);




27 sensor_type_1 : IN STD_LOGIC_VECTOR (7 downto 0);




31 waiting : OUT STD_LOGIC_VECTOR (31 downto 0) );

32 end;

4.1.3. Transmision y Recepcion NXT

Estos componentes se encargan de orquestar el trafico de datos entre la interfaz yel BrickPi utilizando una FIFO para la transmision y otra para la recepcion.

El componente de transmision, descrito en C sintetizable, consiste en una simplemaquina de estados que lee bytes de la FIFO de transmision de la Interfaz NXT (4.1.2) y losescribe en otra FIFO que se conecta con la UART (4.1.1).

Hay dos estados: inactivo y transmitiendo. Cuando se encuentra en el estado detransmitiendo, como se sabe el numero de bytes que se van a enviar (consultar protocoloBrickPi A), se lleva un contador que tras transmitir el ultimo byte de la trama, hace que sevuelva al estado inactivo.

La recepcion se describe tambien en C sintetizable, pero el funcionamiento es massimple que el del componente anterior, ya que carece de maquina de estados, se limita a leerde la FIFO de recepcion de la UART y a escribir a continuacion en la FIFO de recepcion dela Interfaz NXT.

29


4.2. Logica de control

La logica de control constituye la parte algorıtmica del sistema, la cual dota de uncomportamiento especıfico al robot. Como ya se comento previamente, se pretende realizarla logica de control en tres niveles diferentes: integrando directamente la logica en hardwareal componente; utilizando un microprocesador empotrado en la FPGA conectado a la interfazcon el que poder implementar los algoritmos en software; y, por ultimo, enviando ordenes enremoto a traves del puerto serie de la FPGA implementando los algoritmos en un computadorexterno.

A continuacion, se describe cada uno de estos niveles, aunque para su mejor com-prension se recomienda la lectura de los distintos casos de uso expuestos en el capıtulo 5.

4.2.1. Algoritmos en hardware

Los algoritmos de control del robot se programan en C sintetizable respetando lainterfaz del apartado 4.1.2. Es decir, si en la interfaz la velocidad de los motores, su habilita-cion y el tipo de los sensores eran entradas, aquı tendran que ser salidas, y al contrario con elvalor de los sensores y de los encoders, que en la interfaz son salidas y aquı seran entradas.

En definitiva, el algoritmo tomara como entradas las lecturas de los sensores y delos encoders, y, en funcion de sus valores, actuara de una forma u otra, pudiendo cambiar lavelocidad de un motor, pararlo, arrancarlo, etc. De esta manera, es posible construir multiplestipos de comportamiento para el robot, como, por ejemplo, un seguidor de lınea, un brazorobotico, una puerta de parking, etc.

Una vez terminada la especificacion en C sintetizable, y habiendo generado la trans-formacion VHDL, se anadirıa una instancia del componente al top del proyecto, conectandosus entradas y sus salidas a las de la interfaz, ası como al reloj del sistema y a la senal dereset.

30


4.2.2. Microprocesador empotrado

Otra opcion consiste en utilizar un microprocesador soft core integrado en la FPGA,lo que permitira escribir programas en software para ser ejecutados en el microprocesador.

El microprocesador utilizado es el MicroBlaze [Xilg] de Xilinx, que no se encuen-tra fısicamente implementado en la placa, sino que es un soft core desarrollado por Xilinxpara las FPGA.

Para el uso del microprocesador es necesario recurrir a un flujo de diseno distinto,ya que se trata de construir un sistema empotrado algo mas complejo. Para ello Xilinx pro-porciona el Embedded Development Kit (EDK), que incluye una herramienta grafica para eldiseno del sistema modular (XPS). A partir de un diseno basico de partida, que ya incluye elmicroprocesador y los buses principales, se integraran el resto de elementos necesarios, enforma de cores independientes.

El top del componente hardware de la interfaz del robot tiene que ser modificadoligeramente para poder conectarlo con el MicroBlaze. Se anaden a la entidad las diferentesentradas y salidas referentes a los valores de los actuadores y sensores procedentes del com-ponente de la Interfaz NXT. Aparte, es necesario crear un nuevo fichero VHDL que tengacomo componente el top anterior y como entidad: las senales de reloj, reset, transmision yrecepcion, y dos interfaces AXI4 [Xil11], una master y otra slave, con las senales data (de32 bits), valid, ready y last tıpicas (aunque la de last no se usa).

El nuevo componente tiene por nombre nxt stream y se integra dentro de un pro-yecto XPS como un pcore. Para construir el pcore es necesario crear una estructura de direc-torios con un formato definido y una serie de ficheros de configuracion. Dentro del directorioraız del pcore hay tres subdirectorios: data, hdl y netlist. En el primero hay que crear tresficheros:

BBD (Black Box Definition): Contiene un listado con los ficheros netlist utilizados enel componente. En este caso, la FIFO de la UART.

1 FILES

2 uart_fifo.ngc

MPD (Microprocessor Peripheral Definition): Define la interfaz de los perifericos: una

31


lista de puertos y su conectividad con las interfaces de los buses, y una lista de parame-tros y valores por defecto.

1 BEGIN nxt_stream

2

3 ## Peripheral Options

4 OPTION IPTYPE = PERIPHERAL

5 OPTION IMP_NETLIST = TRUE

6 OPTION HDL = VHDL

7 OPTION STYLE = MIX

8 OPTION ARCH_SUPPORT_MAP = (virtex6 = AVAILABLE)

9 ## Bus Interfaces

10 BUS_INTERFACE BUS=M_AXIS, BUS_STD=AXIS, BUS_TYPE=INITIATOR

11 BUS_INTERFACE BUS=S_AXIS, BUS_STD=AXIS, BUS_TYPE=TARGET

12

13 ## Parameters

14 PARAMETER C_S_AXIS_PROTOCOL = GENERIC, DT = string, TYPE =

NON_HDL, ASSIGNMENT = CONSTANT, BUS = S_AXIS

15 PARAMETER C_S_AXIS_TDATA_WIDTH = 32, DT = integer, TYPE =

NON_HDL, ASSIGNMENT = CONSTANT, BUS = S_AXIS

16 PARAMETER C_M_AXIS_PROTOCOL = GENERIC, DT = string, TYPE =

NON_HDL, ASSIGNMENT = CONSTANT, BUS = M_AXIS

17 PARAMETER C_M_AXIS_TDATA_WIDTH = 32, DT = integer, TYPE =

NON_HDL, ASSIGNMENT = CONSTANT, BUS = M_AXIS

18

19

20 ## Peripheral ports

21 PORT clk = "", DIR=I, SIGIS=CLK, BUS=M_AXIS:S_AXIS

22 PORT rst = "", DIR=I, SIGIS=RST, ASSIGNMENT = REQUIRE

23 PORT S_AXIS_TREADY = TREADY, DIR=O, BUS=S_AXIS

24 PORT S_AXIS_TDATA = TDATA, DIR=I, VEC=[31:0], BUS=S_AXIS

25 PORT S_AXIS_TLAST = TLAST, DIR=I, BUS=S_AXIS

26 PORT S_AXIS_TVALID = TVALID, DIR=I, BUS=S_AXIS

27 PORT M_AXIS_TVALID = TVALID, DIR=O, BUS=M_AXIS

28 PORT M_AXIS_TDATA = TDATA, DIR=O, VEC=[31:0], BUS=M_AXIS

29 PORT M_AXIS_TLAST = TLAST, DIR=O, BUS=M_AXIS

30 PORT M_AXIS_TREADY = TREADY, DIR=I, BUS=M_AXIS

31 PORT RX = "", DIR=I

32 PORT TX = "", DIR=O

33

34 END

PAO (Peripheral Analyze Order): Contiene una lista de los ficheros VHDL necesariospara la sıntesis.

1 lib nxt_stream_v1_00_a nxt_stream vhdl

2

3 lib nxt_stream_v1_00_a nxt_top vhdl

4

32


5 lib nxt_stream_v1_00_a uart vhdl

6 lib nxt_stream_v1_00_a uart_axi vhdl

7

8 lib nxt_stream_v1_00_a nxt_tx vhdl

9 lib nxt_stream_v1_00_a nxt_rx vhdl

10

11 lib nxt_stream_v1_00_a add_bits vhdl

12 lib nxt_stream_v1_00_a get_bits vhdl

13 lib nxt_stream_v1_00_a nxt_iface_Array vhdl

14 lib nxt_stream_v1_00_a nxt_iface_Array_1 vhdl

15 lib nxt_stream_v1_00_a nxt_iface_Array_3 vhdl

16 lib nxt_stream_v1_00_a wait_r vhdl

17 lib nxt_stream_v1_00_a nxt_iface vhdl

En el directorio hdl hay otro directorio con nombre vhdl, y dentro de el, todos losficheros VHDL necesarios para la sıntesis. En el directorio netlist se encuentran los ficherosngc necesarios para el componente.

Una vez integrado el pcore en el proyecto, se puede instanciar en el mismo. Seinstancian tambien un MicroBlaze, una UART y un bus AXI. La UART, que sirve paraacceder a la entrada y salida estandar del MicroBlaze, se conecta a el a traves del bus AXI.Sin embargo, el componente nxt stream se conecta directamente como coprocesador [Xilb]al MicroBlaze con las interfaces AXI en una conexion punto a punto. Se podrıa conectartambien al bus AXI, como la UART, pero esto implicarıa aumentar la complejidad al tenerque arbitrar el bus para el acceso al mismo, y, como no se van a conectar mas perifericos alMicroBlaze, se opta por la conexion punto a punto.

Una vez conectados todos los puertos, se sintetizarıa el proyecto y se exportarıaal EDK (Embedded Development Kit), donde se programaran los algoritmos de control delrobot para ser ejecutados en el MicroBlaze utilizando la interfaz hardware.

4.2.3. Programacion remota

La tercera y ultima opcion consiste en ejecutar los algoritmos en un computadorexterno enviando y recibiendo los datos relativos a los sensores y los actuadores a traves delpuerto serie de la FPGA.

Para ello, es necesario crear un nuevo proyecto en la herramienta XPS. En el, sevolvera a instanciar el componente nxt stream de la interfaz de los sensores y actuadores

33


creado e integrado dentro de la herramienta como un pcore.

Ademas de este componente, sera necesario utilizar una UART que controle lacomunicacion por el puerto serie que se va a utilizar. Para ello, se reutiliza la UART utilizadaen el apartado 4.1.1 haciendo unas ligeras modificaciones. La UART referida utiliza un anchode 8 bits para los datos que envıa y recibe, sin embargo, la interfaz AXI del componentenxt stream utiliza un ancho de 32 bits. Para solucionar esto, se modificaran las interfaces desalida y entrada de datos de la UART a un ancho de 32 bits, pero manteniendo por dentro, enel control, una anchura de 8 bits. Como el lector recordara, este componente UART utilizabados colas FIFO, una para la recepcion, y otra para la transmision, ambas con un ancho dedatos de 8 bits. Aparte del cambio realizado antes, hace falta regenerar las FIFO para quese adapten a los nuevos anchos de bit, es decir, la FIFO de transmision tendra 32 bits enla entrada (procedente del exterior del componente) y 8 bits en la salida (dirigido hacia elinterior), y la FIFO de recepcion, al contrario, 8 bits en la entrada (procedente del interior) y32 bits en la salida (hacia el exterior).

Terminada la modificacion del componente, se creara con el otro pcore que se ins-tanciara en el proyecto, conectando sus interfaces AXI con las del componente nxt stream ysus senales Tx y Rx con los pines de la FPGA del puerto serie.

34

5 Caso de uso

Indice5.1. Algoritmos en hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2. Microprocesador empotrado . . . . . . . . . . . . . . . . . . . . . . . 39

5.3. Programacion remota . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

En este capıtulo se describe una demostracion de uso de la plataforma de proto-tipado, explicando como programar para cada nivel de logica de control (hardware, micro-procesador empotrado o en remoto) un sencillo ejemplo de comportamiento del robot, enconcreto, una barrera de parking.

Para construir la maqueta se necesitan un sensor de luz [2.1.2], dos sensores decontacto [2.1.2], un servo motor [2.1.3] y varias piezas de montaje. La Figura 5.1 muestra lamaqueta montada.

El comportamiento de la barrera de parking se puede realizar con una sencillamaquina de estados que, partiendo de un estado inicial, active el motor de la barrera cuandoel sensor de luz utilizado detecte un obstaculo frente a el. El sensor de luz toma valores masaltos (de 0 a 1023) cuando menos luz recibe, por lo que se puede establecer como trigger

un valor mayor de 700. Cuando la barra active el sensor de pulsacion superior, el motor separara y se cambiara de estado. Se permanece ası hasta que el sensor de luz deje de detectarel obstaculo frente a el, es decir, cuando devuelva un valor menor o igual que 700; entonces,

5. Caso de uso

Figura 5.1: Maqueta de una barrera de parking montada con piezas de Lego NXT

el motor se activara de nuevo pero con la direccion invertida (velocidad negativa), cambian-do de nuevo de estado. Por ultimo, cuando la barrera toca el sensor de pulsacion inferior, elmotor se para y se vuelve al estado inicial.

5.1. Algoritmos en hardware

Los algoritmos se programan en C sintetizable en la herramienta Vivado HLS.

Se crea un proyecto nuevo configurandolo para la FPGA utilizada (ver Anexo B)y se establece como top una funcion que toma como entradas los encoders de los motoresy los valores de los sensores, y como salidas, la velocidad de los motores, la habilitacion delos motores y el tipo de los sensores, como:

36

5.1. Algoritmos en hardware

1 void nxt_boom_barrier(short* m1_speed, short* m2_speed, short*m3_speed, short* m4_speed, unsigned char* m1_enable, unsignedchar* m2_enable, unsigned char* m3_enable, unsigned char*m4_enable, int encoder1, int encoder2, int encoder3, intencoder4, unsigned char* sensor_type_1, unsigned char*sensor_type_2, unsigned char* sensor_type_3, unsigned char*sensor_type_4, short sensor1, short sensor2, short sensor3,

short sensor4);

A continuacion, dentro de la funcion, se escribe el codigo C que simula el compor-tamiento de la barrera de parking descrito antes.

1 unsigned char state = st_IDLE;

2

3 // Motors speed (0 - 255)

4 *m1_speed = 50;

5 *m2_speed = 0;

6 *m3_speed = 0;

7 *m4_speed = 0;

8 *m1_enable = 0;

9 *m2_enable = 0;

10 *m3_enable = 0;

11 *m4_enable = 0;

12

13 *sensor_type_1 = 0; // Light sensor (0 - 1023)

14 *sensor_type_2 = 0; // Upper touch sensor (˜1023 (0) o ˜180 (1))

15 *sensor_type_3 = 0; // Bottom touch sensor (˜1023 (0) o ˜180 (1))

16 *sensor_type_4 = 0;

17

18 while (1) {

19 switch (state) {

20 case st_IDLE:

21 if (sensor1 > 700) {

22 *m1_enable = 1;

23 state = st_GOING_UP;

24 }

25 break;26 case st_GOING_UP:

27 if (sensor2 < 200) {

28 *m1_enable = 0;

29 state = st_UP;

30 }

31 break;32 case st_UP:

33 if (sensor1 <= 700) {

34 *m1_speed = -50;

35 *m1_enable = 1;

36 state = st_GOING_DOWN;

37

5. Caso de uso

37 }

38 break;39 case st_GOING_DOWN:

40 if (sensor3 < 200) {

41 *m1_enable = 0;

42 *m1_speed = 50;

43 state = st_IDLE;

44 }

45 break;46 }

47 }

El control y la sensorizacion son tan simples como la escritura y lectura de variablesen C, siendo la herramienta de sıntesis la que traduce esas operaciones a la activacion desenales necesaria.

La transformacion a VHDL del codigo anterior genera la siguiente entidad, quecasa con la Interfaz NXT (4.1.2):

1 entity nxt_boom_barrier is2 port (

3 ap_clk : IN STD_LOGIC;

4 ap_rst : IN STD_LOGIC;

5 m1_speed : OUT STD_LOGIC_VECTOR (15 downto 0);




9 m1_enable : OUT STD_LOGIC_VECTOR (7 downto 0);




13 encoder1 : IN STD_LOGIC_VECTOR (31 downto 0);




17 sensor_type_1 : OUT STD_LOGIC_VECTOR (7 downto 0);

18 sensor_type_2 : OUT STD_LOGIC_VECTOR (7 downto 0);



21 sensor1 : IN STD_LOGIC_VECTOR (15 downto 0);



24 sensor4 : IN STD_LOGIC_VECTOR (15 downto 0));

25 end;

Por tanto, para integrar el algoritmo de control de la barrera, basta con incluir el

38

5.2. Microprocesador empotrado

componente VHDL y conectar sus entradas y salidas con la de la Interfaz NXT.

Como se puede comprobar, la creacion de algoritmos en hardware para la plata-forma resulta de extrema sencillez gracias a la sıntesis de alto nivel, y al poder simular losalgoritmos directamente en C, es posible generar algoritmos en un tiempo mucho menor quesi se codificasen directamente en HDL. El mayor inconveniente de esta opcion de prototipadoes que es necesario resintetizar todo el proyecto.


Los algoritmos se programan en C y se ejecutan como software en el micropro-cesador software, MicroBlaze, empotrado en la FPGA. Para ello, tras haber exportado laespecificacion de la plataforma hardware (HPS, Hardware Platform Specification) al SDK,se crea un proyecto BSP (Board Support Package) de tipo standalone, ya que los accesosque se realizan al MicroBlaze son muy basicos y no se necesita la intervencion de un sistemaoperativo.

Una vez creados tanto el HPS como el BSP, ya se pueden proyectos software parala plataforma en codigo C.

En primer lugar, hay que construir dos funciones, una put para escribir datos enel puerto serie, y otra get, para leerlos. Estas dos funciones seran el punto de conexion conla plataforma de prototipado. Han de llamarse siempre juntas, una detras de otra (primeroput y despues get), porque el componente VHDL que gestiona la salida y entrada de datoses una maquina de estados que espera primero las escrituras de los diferentes valores de losactuadores y sensores, y despues, las lecturas de los sensores y encoders, por lo que si seejecutasen por separado o en distinto orden, no funcionarıa, o funcionarıa mal. Para evitaresto, se construye otra funcion, update values, que simplemente llame a las dos anteriores.Las escrituras y lecturas se hacen con las funciones putfslx y getfslx del fichero de cabecera“fsl.h”, respectivamente. Como las interfaces AXI utilizadas tienen un ancho de 32 bits, losdatos que se escriban y lean, han de tener tambien ese ancho.

Estas funciones seran comunes a todos los algoritmos que se programen:

1 void put(short m1_speed, short m2_speed, short m3_speed, shortm4_speed, unsigned char m1_enable, unsigned char m2_enable,

unsigned char m3_enable, unsigned char m4_enable, unsigned char

39

5. Caso de uso

sensor_type_1, unsigned char sensor_type_2, unsigned charsensor_type_3, unsigned char sensor_type_4) {

2 uint32_t speeds_12 = (m1_speed << 16) | m2_speed;

3 uint32_t speeds_34 = (m3_speed << 16) | m4_speed;

4 uint32_t enables = (m1_enable << 24) | (m2_enable << 16) | (

m3_enable << 8) | m4_enable;

5 uint32_t types = (sensor_type_1 << 24) | (sensor_type_2 << 16)

| (sensor_type_3 << 8) | sensor_type_4;

6

7 putfslx(speeds_12, 0, FSL_DEFAULT);

8 putfslx(speeds_34, 0, FSL_DEFAULT);

9 putfslx(enables, 0, FSL_DEFAULT);

10 putfslx(types, 0, FSL_DEFAULT);

11 }

12

13 void get(long* encoder1, long* encoder2, long* encoder3, long*encoder4, short* sensor1, short* sensor2, short* sensor3, short*sensor4) {

14 uint32_t sensors_12 = 0, sensors_34 = 0;

15 getfslx(*encoder1, 0, FSL_DEFAULT);




19 getfslx(sensors_12, 0, FSL_DEFAULT);

20 *sensor1 = sensors_12 >> 16;

21 *sensor2 = sensors_12;

22 getfslx(sensors_34, 0, FSL_DEFAULT);

23 *sensor3 = sensors_34 >> 16;

24 *sensor4 = sensors_34;

25 }

26

27 void update_values(short m1_speed, short m2_speed, short m3_speed,

short m4_speed,

28 unsigned char m1_enable, unsigned char m2_enable,

unsigned char m3_enable, unsigned char m4_enable

,

29 unsigned char sensor_type_1, unsigned charsensor_type_2, unsigned char sensor_type_3,

unsigned char sensor_type_4,

30 long* encoder1, long* encoder2, long* encoder3,

long* encoder4,

31 short* sensor1, short* sensor2, short* sensor3,

short* sensor4) {

32 put(m1_speed, m2_speed, m3_speed, m4_speed, m1_enable,

m2_enable, m3_enable, m4_enable, sensor_type_1,

sensor_type_2, sensor_type_3, sensor_type_4);

33 get (&encoder1, &encoder2, &encoder3, &encoder4, &sensor1,

&sensor2, &sensor3, &sensor4);

34 }

40


En el main se implementa el algoritmo mediante una maquina de estados que seejecuta constantemente en un bucle infinito mientras se van actualizando los valores de lossensores y actuadores al llamar a la funcion update values:

1 int main()

2 {

3 init_platform();

4

5 short m1_speed, m2_speed, m3_speed, m4_speed;

6 unsigned char m1_enable, m2_enable, m3_enable, m4_enable,

7 sensor_type_1, sensor_type_2, sensor_type_3, sensor_type_4;

8

9 long encoder1, encoder2, encoder3, encoder4;

10 short sensor1, sensor2, sensor3, sensor4;

11

12 unsigned char state = ST_IDLE;

13

14 m1_speed = 50;

15 m2_speed = 200;

16 m3_speed = 200;

17 m4_speed = 200;

18

19 m1_enable = 0;

20 m2_enable = 1;

21 m3_enable = 1;

22 m4_enable = 1;

23

24 sensor_type_1 = 0;




28

29 while (1) {

30 update_values(m1_speed, m2_speed, m3_speed, m4_speed,

m1_enable, m2_enable, m3_enable, m4_enable,

sensor_type_1, sensor_type_2, sensor_type_3,

sensor_type_4, &encoder1, &encoder2, &encoder3, &

encoder4, &sensor1, &sensor2, &sensor3, &sensor4);

31

32 switch(state) {

33 case ST_IDLE:

34 if (sensor1 > 700) {

35 m1_enable = 1;

36 state = ST_GOING_UP;

37 }

38 break;39 case ST_GOING_UP:

40 if (sensor4 < 200) {

41 m1_enable = 0;

42 state = ST_UP;

41

5. Caso de uso

43 }

44 break;45 case ST_UP:

46 if (sensor1 <= 700) {

47 m1_speed = -50;

48 m1_enable = 1;

49 state = ST_GOING_DOWN;

50 }

51 break;52 case ST_GOING_DOWN:

53 if (sensor2 < 200) {

54 m1_enable = 0;

55 m1_speed = 50;

56 state = ST_IDLE;

57 }

58 break;59 }

60 }

61 return 0;

62 }

Como se ve, salvo por algunos detalles, la sintaxis es practicamente identica a ladel codigo C sintetizable del apartado anterior.

Para probar el algoritmo en la placa hay que descargar el bitstream a la misma ydespues, en la herramienta XMD (Xilinx Microprocessor Debugger) para interaccionar conel MicroBlaze, ejecutar las siguientes ordenes:

1 connect mb mdm

2 dow <nombre_del_proyecto>.elf

3 run

El fichero .elf se encuentra en el subdirectorio Debug del proyecto EDK.

5.3. Programacion remota

Para programar algoritmos que se ejecuten en remoto, conectandose mediante elpuerto serie a la FPGA, basta con escribir un programa en un lenguaje de programacioncon librerıas para escribir en y leer del puerto serie. El ejemplo que se va a desarrollar acontinuacion esta escrito en Python [Pyt].

42


Al igual que en la programacion del apartado anterior, es necesario crear funcionesput y get para escribir y leer, aunque en este caso se hace en el puerto serie. Las funcionesputfslx y getfslx utilizadas en el proyecto software del MicroBlaze escribıan y leıan siempredatos de 32 bits, sin embargo, la librerıa de acceso al puerto serie de Python permite envıary recibir datos de diferentes anchos, por eso es muy importante tener especial cuidado conel ancho de bits de cada valor que se escribe y se lee, ası como con el formato en el que sealmacenan (little-endian o big-endian).

Las funciones put, get y update values en Python quedarıan ası:

1 def put(m1_speed, m2_speed, m3_speed, m4_speed, m1_enable,

m2_enable, m3_enable, m4_enable, sensor_type_1, sensor_type_2,

sensor_type_3, sensor_type_4):

2 ser.write(struct.pack(’!hhhhBBBBBBBB’, m1_speed, m2_speed,

m3_speed, m4_speed, m1_enable, m2_enable, m3_enable,

m4_enable, sensor_type_1, sensor_type_2, sensor_type_3,

sensor_type_4))

3

4 def get():

5 res = ser.read(4)

6 encoder1 = (ord(res[0]) << 24) | (ord(res[1]) << 16) | (ord

(res[2]) << 8) | ord(res[3])

7 res = ser.read(4)


(res[2]) << 8) | ord(res[3])

9 res = ser.read(4)


(res[2]) << 8) | ord(res[3])

11 res = ser.read(4)


(res[2]) << 8) | ord(res[3])

13


15 sensor1 = (ord(res[0]) << 8) | (ord(res[1]))


17




21

22 return encoder1, encoder2, encoder3, encoder4, sensor1,

sensor2, sensor3, sensor4

23

24 def update_values(m1_speed, m2_speed, m3_speed, m4_speed, m1_enable

, m2_enable, m3_enable, m4_enable, sensor_type_1, sensor_type_2,

sensor_type_3, sensor_type_4):

25 put(m1_speed, m2_speed, m3_speed, m4_speed, m1_enable,

m2_enable, m3_enable, m4_enable, sensor_type_1,

43

5. Caso de uso

sensor_type_2, sensor_type_3, sensor_type_4)

26 encoder1, encoder2, encoder3, encoder4, sensor1, sensor2,

sensor3, sensor4 = get()

27

28 return encoder1, encoder2, encoder3, encoder4, sensor1,

sensor2, sensor3, sensor4

Despues, basta con abrir el puerto serie (y cerrarlo antes, por si estuviese abierto)con la direccion adecuada y una tasa de baudios de 115200 bps (que fue la que se asigno enel proyecto), e implementar el algoritmo de igual forma que se hizo en los casos anteriores,solo que en sintaxis de Python:

1 ser = serial.Serial(

2 port=’/dev/ttyUSB1’,

3 baudrate=115200)

4

5 ser.close()

6 ser.open()

7

8 m1_speed = 50

9 m2_speed = 0

10 m3_speed = 0

11 m4_speed = 0

12

13 m1_enable = 0

14 m2_enable = 0

15 m3_enable = 0

16 m4_enable = 0

17

18 sensor_type_1 = 0




22

23 state = 0

24 while 1:

25 encoder1, encoder2, encoder3, encoder4, sensor1, sensor2,

sensor3, sensor4 = update_values(m1_speed, m2_speed,

m3_speed, m4_speed, m1_enable, m2_enable, m3_enable,

m4_enable, sensor_type_1, sensor_type_2, sensor_type_3,

sensor_type_4)

26

27 if state == 0:

28 if sensor1 > 700:

29 m1_speed = 50

30 m1_enable = 1

31 state = 1

32 elif state == 1:

44


33 if sensor4 < 200:

34 m1_enable = 0

35 m1_speed = -50

36 state = 2

37 elif state == 2:

38 if sensor1 <= 700:

39 m1_enable = 1

40 state = 3

41 elif state == 3:

42 if sensor2 < 200:

43 m1_enable = 0

44 state = 0

45

6 Metodos y fases de trabajo

Indice6.1. BrickPi: Ingenierıa inversa . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2. Fases de la programacion hardware . . . . . . . . . . . . . . . . . . . 48

El primer paso en la realizacion de este proyecto es la ingenierıa inversa del proto-colo utilizado por BrickPi para comunicarse (transmision y recepcion de datos) con el robot.Este protocolo se encuentra explicado en el Anexo A. Tras esto, se puede empezar a construirel sistema.

Teniendo en cuenta la arquitectura del sistema, que se compone de distintos modu-los hardware que al final se conectaran entre sı, resulta obvio decir que el metodo de trabajose realizara mediante una programacion modular. Es decir, se implementara cada modulo, deprincipio a fin, uno detras de otro.

La implementacion de cada modulo sigue una serie de etapas que se describiranmas adelante, algunas de las cuales se explican en la guıa de sıntesis de alto nivel de laherramienta Vivado HLS [Xili] [Xilj].

Una vez finalizada la implementacion de todos los modulos, se procede a la inte-gracion de los mismos, conformando ası sistema final.

Por ultimo, solo quedarıa el desarrollo de demostradores para comprobar el siste-

6. Metodos y fases de trabajo

ma.

6.1. BrickPi: Ingenierıa inversa

El metodo para realizar la ingenierıa inversa del BrickPi consiste en:

Analisis de los drivers: Mediante el analisis del codigo de los drivers, que se puedeencontrar en la pagina web del desarrollador [Dexa], se intenta descifrar su funciona-miento.

Pruebas de ejecucion: Creando programas simples que provoquen un efecto en el roboty analizando los datos que se mandan mediante la depuracion del codigo fuente. Estaspruebas se realizan en una Raspberry Pi con el BrickPi conectado a los pines GPIO.

Depuracion fısica: Mediante el uso de un osciloscopio, se analiza la senal digital queel BrickPi envıa al robot y tambien la que recibe de el. De esta manera se conocede forma exacta lo que se esta enviando y recibiendo y los tiempos entre cada tramaenviada o recibida.

6.2. Fases de la programacion hardware

El desarrollo de los componentes se realiza mediante la ejecucion de una serie defases que se describen a continuacion.

La mayorıa de las partes del proyecto se realizaran mediante sıntesis de alto nivel,aunque algunas se programaran directamente en VHDL por limitaciones de la HLS.

En primer lugar, en la fase de especificacion se programan los algoritmos y pro-tocolos en C para sıntesis de alto nivel teniendo en cuenta las diferentes restricciones de lasıntesis y directivas que el usuario puede indicar. La programacion se realiza mediante la he-rramienta para sıntesis de alto nivel de Xilinx, Vivado HLS. Es un entorno de programacionbasado en Eclipse en el que se programa, se simula y se genera la sıntesis RTL.

Una vez realizada la especificacion, se comprueba la correcta funcionalidad delcodigo programado. Como en HLS el codigo se compone de funciones, siendo una de ellas la

48


principal o top que llama a las demas, es necesario crear un fichero de testbench que invoqueal top para realizar la comprobacion de la funcionalidad. Las pruebas que se realizan, seespera que tengan una salida o resultado concreto, en la ejecucion se compara el resultadoesperado con el obtenido, y, en caso de no coincidir, habra que realizar una depuracion delcodigo y regresar a la fase de especificacion.

Una vez que la validacion funcional haya devuelto un resultado satisfactorio, seejecuta en Vivado HLS la sıntesis RTL (Register-transistor logic), que transforma el codigoC en VHDL y otros lenguajes de descripcion de hardware, y genera un informe en el que semuestran los distintos parametros hardware establecidos, como pueden ser: el ciclo de reloj,los retardos, el rendimiento, el consumo, etc.

Aquı terminarıa la parte de programacion en sıntesis de alto nivel. Las siguientesetapas se realizan tanto para los modulos programados directamente en VHDL como en losgenerados mediante HLS. Tambien se pueden generar automaticamente diferentes tipos decomponentes, como elementos de memoria, multiplicadores, buses, etc. con Coregen, unaherramienta para la generacion de cores configurables y optimizados para una arquitecturaconcreta de FPGA.

El proyecto se integra en XPS (Xilinx Platform Studio), que es una herramientapara la creacion de proyectos hardware, especificando el tipo de placa para la que se va atrabajar y pudiendo anadir componentes realizados por el usuario o generados por la pro-pia herramienta. Se realizan las conexiones entre componentes conectandolos a los buses yasignandoles una direccion. Es capaz de generar el bitstream del proyecto y descargarlo enla placa de prototipado.

Se acopla el componente al top del proyecto, o dentro de algun otro componenteconectando, sus entradas y salidas a senales o a otras entradas y salidas.

A continuacion, se puede simular el funcionamiento del proyecto mediante la he-rramienta de simulacion Questasim, utilizando para ello un testbench en VHDL.

Despues, se genera la netlist, que es un fichero que contiene la informacion deconectividad de un diseno electronico. Se genera a partir de los codigos VHDL y de losdistintos ficheros de configuracion de puertos y de los pines de la placa. Si se producenerrores durante la generacion, puede significar que el codigo VHDL tenga errores o que elproyecto este mal configurado. Se detectan y se corrigen los errores.

49

6. Metodos y fases de trabajo

Con la netlist generada, se puede generar el fichero llamado bitstream que sirvepara programar la FPGA. La generacion del bitstream consiste en el mapeo de los elementoslogicos, es decir, agrupar las puertas logicas de la netlist en componentes fısicos; y en elemplazamiento y enrutado de los componentes. La fase de emplazamiento decide donde sevan a situar en la FPGA los diferentes elementos del diseno electronico. A continuacion, lafase de enrutado decide el diseno exacto de la conexion de los componentes emplazados enla fase anterior. Por ultimo, una vez generado el bitstream, se vuelca el modulo hardwaresintetizado en la plataforma de prototipado.

Una vez programada la FPGA, se comprueba que su comportamiento sea el espe-rado. Para ello se puede hacer uso de distintas herramientas, como ChipScope [Xila], quepermiten el analisis de ciertas senales que fueron especificadas previamente en el codigo.Tambien se ha utilizado en este proyecto un osciloscopio para comprobar las senales emiti-das y recibidas y asegurar que son las correctas y que la separacion temporal entre ellas es laque debe.

Una vez terminada esta fase, si los resultados han sido satisfactorios, la producciondel modulo habrıa finalizado, en caso contrario, habrıa que volver al principio para corregirlos errores que se hayan producido.

La Figura 6.1 muestra un diagrama de flujo de la metodologıa previamente descrita.

50


Figura 6.1: Diagrama de flujo de la metodologıa de programacion hardware

51

7 Resultados y conclusiones

Indice7.1. Resultados de la sıntesis . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.1.1. Algoritmos en hardware . . . . . . . . . . . . . . . . . . . . . . 54

7.1.2. Microprocesador empotrado . . . . . . . . . . . . . . . . . . . . 54

7.1.3. Programacion en remoto . . . . . . . . . . . . . . . . . . . . . . 55

7.2. Coste del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.4. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1. Resultados de la sıntesis

A continuacion, se muestran los resultados de la sıntesis sobre los diferentes tiposde recursos utilizados de la FPGA, que es una Virtex-6 ML605 configurada para funcionar auna velocidad de 125 MHz, y los tiempos para cada uno de los tres niveles para el desarrollode algoritmos.

7. Resultados y conclusiones

7.1.1. Algoritmos en hardware

La Tabla 7.1 muestra los recursos utilizados, los disponibles y el porcentaje deutilizacion y la Tabla 7.2 muestra el periodo mınimo y la frecuencia maxima del reloj.

Bloque logico Usado Disponible UtilizacionRegistros 1956 301440 <0 %LUT 2035 150720 1 %

Logica 1905 150720 1 %Memoria 130 58400 <0 %

BRAM 23 416 5 %

Tabla 7.1: Utilizacion del dispositivo para el metodo de algoritmos en hardware

Periodo mınimo Frecuencia maxima5,480 ns 182,482 MHz

Tabla 7.2: Tiempos para el metodo de algoritmos en hardware

7.1.2. Microprocesador empotrado

La Tabla 7.3 muestra los recursos utilizados estimados; la Tabla 7.4 muestra losrecursos utilizados, los disponibles y el porcentaje de utilizacion; y la Tabla 7.5 muestra elperiodo mınimo y la frecuencia maxima del reloj.

Componente Flip Flops LUT BRAMTotal del sistema 3873 4267 10Drivers NXT 1587 1934 4RS232 UART 89 116MicroBlaze 1682 1657

Tabla 7.3: Valores estimados de la sıntesis para el metodo con microprocesador empotrado

Bloque logico Usado Disponible UtilizacionRegistros 3155 301440 1 %LUT 3602 150720 2 %

Logica 3323 150720 2 %Memoria 194 58400 1 %

BRAM 4 416 1 %

Tabla 7.4: Utilizacion del dispositivo para el metodo con microprocesador empotrado

54

7.2. Coste del proyecto


Tabla 7.5: Tiempos para el metodo con microprocesador empotrado

7.1.3. Programacion en remoto

La Tabla 7.6 muestra los recursos utilizados estimados; la Tabla 7.7 muestra losrecursos utilizados, los disponibles y el porcentaje de utilizacion; y la Tabla 7.8 muestra elperiodo mınimo y la frecuencia maxima del reloj.

Componente Flip Flops LUT BRAMTotal del sistema 2697 2838 9Drivers NXT 1587 1934 4UART AXI 392 259

Tabla 7.6: Valores estimados de la sıntesis para el metodo en remoto

Bloque logico Usado Disponible UtilizacionRegistros 2605 301440 1 %LUT 2460 150720 1 %

Logica 2173 150720 1 %Memoria 77 58400 1 %

BRAM 3 416 1 %

Tabla 7.7: Utilizacion del dispositivo para el metodo en remoto


Tabla 7.8: Tiempos para el metodo en remoto

7.2. Coste del proyecto

El coste total del proyecto se compone de una serie de gastos en herramientashardware y software, mano de obra y costes indirectos.

Segun el reglamento de procedimiento para la contratacion de personal con cargo aproyectos I+D+i con financiacion externa en la Universidad de Castilla-La Mancha [Uni], untitulado en Ingenierıa Informatica costarıa 27.019,22 C al ano, incluyendo sueldo, seguridad

55


social, etc. Si esa cifra se divide entre 12 meses, y el resultado se divide entre 140 horasmensuales:

27019, 22 C /12 = 2251, 6 C

2251, 6 C /140 horas = 16, 08 C / hora

Habiendo invertido, aproximadamente, unas 350 horas a la realizacion del proyec-to, el coste total de la contratacion del ingeniero serıa de:

16, 08 C / hora x 350 horas = 5628 C

Tambien hay que tener en cuenta a la hora de calcular el presupuesto final los costesindirectos, que son aquellos que no estan vinculados directamente al proyecto, pero que sonnecesarios para que el mismo se desarrolle. Por ejemplo, lo que cuesta a la Escuela mante-ner abierto el edificio, los costes electricidad de los aparatos utilizados, el aprovechamientode ordenadores y otras herramientas, etc. Los costes indirectos son muy complejos de de-terminar, por eso, muchas veces, para simplificar, se establece como gastos indirectos unporcentaje del resto del proyecto. Por ejemplo, para este caso, se considera que el 12 % delresto de gastos corresponden a gastos indirectos.

A continuacion, se muestra el desglose total del presupuesto del proyecto. Losartıculos listados se muestran con el IVA ya aplicado.

Artıculo Precio/unidad Cantidad Precio totalVirtex-6 FPGA ML605 Evaluation Kit 1336,56 C 1 1336,56 CFMC XM105 Debug Card 118,4 C 1 118,4 CBrickPi 48,40 C 1 48,40 CLEGO Mindstorms NXT 2.0 394,6 C 1 394,6 CRaspberry Pi B 30 C 1 30 CNVE IL710-2E 4,16 C 2 8,32 CIngeniero Informatico 16,08 C/hora 350 horas 5628 CTotal costes directos 7564,28 CCostes indirectos (12 %) 907,71 CTOTAL 8471,99 C

Tabla 7.9: Costes desglosados del proyecto

56

7.3. Conclusiones

7.3. Conclusiones

En el capıtulo 3 se establecio como objetivo general la creacion de un entorno deprototipado para el desarrollo de algoritmos y aplicaciones sobre robots moviles Lego NXT.

Para llegar a este objetivo general, ha sido necesario cumplir los objetivos especıfi-cos que se establecieron junto al general:

Se realizo una ingenierıa inversa que permitio comprender el funcionamiento del pro-tocolo utilizado por el BrickPi para su comunicacion con los diferentes sensores yactuadores del robot.

Se conectaron los distintos componentes fısicos usados en la plataforma, teniendo queconstruir para ello un pequeno circuito con dos optoacopladores (ver Anexo B).

Se programaron la mayorıa de componentes mediante sıntesis de alto nivel, salvo laUART.

Se construyeron con exito las tres vıas para el desarrollo de algoritmos sobre los robots.

Se desarrollo un ejemplo de funcionamiento (una barrera de parking) del robot bajocada uno de los tres metodos, produciendo en todos un resultado exitoso.

Se concluye, por tanto, que la plataforma creada es capaz de generar de formaeficiente y sencilla algoritmos en hardware, en software o en una combinacion de ambos.Ademas, cabe destacar el buen hacer de la sıntesis de alto nivel para el desarrollo de loscomponentes hardware, que permite generar algoritmos en hardware de manera sencilla, enun lenguaje de alto nivel, y simularlo como tal, produciendo un gran ahorro de tiempo encomparacion con la programacion en HDL.

Sin embargo, existen ciertas limitaciones en la sıntesis de alto nivel que hacenque sea difıcil modelar procesos concurrentes. Por eso, la UART, que en un principio seintento implementar en HLS, se desarrollo finalmente en VHDL.

En cuanto a los recursos de la FPGA utilizados por el proyecto, como se ha podidover en la seccion 7.1, son ınfimos, entre el 1 y el 5 %. Por tanto, podrıa utilizarse una FPGAde menor rango sin temor a una falta de recursos.

57


7.4. Trabajo futuro

Las grandes dimensiones de la FPGA y el hecho de que tenga que estar conectadaa la corriente mediante una fuente de alimentacion hacen que la movilidad del robot seacasi nula. Por ello, un punto muy importante a tener en cuenta como trabajo futuro serıa laminituarizacion de la placa utilizando otro modelo de FPGA con dimensiones reducidas quesea facilmente acoplable al robot y una baterıa, dando ası libertad de movimiento al robot yampliando las posibilidades de la plataforma. Ademas, como ya se dijo antes, los resultadosde la sıntesis muestran que el porcentaje de recursos utilizados de la FPGA es muy pequeno,por lo que no habrıa problema en utilizar una FPGA de menor tamano.

Tambien entra dentro de los planes de futuro desarrollar otro nivel de hardware quefuese mas alla de los drivers y que proporcionase una serie de primitivas basicas para el usodel robot, como, por ejemplo, mover un motor durante un determinado tiempo y que despuesse pare.

Otra opcion de extension futura podrıa ser la sustitucion de la funcionalidad pro-porcionada por el BrickPi, proveyendola directamente desde la FPGA. Con ello se reducirıael numero de componentes del sistema, ası como el consumo de energıa, y por lo tanto lasnecesidades de baterıa.

58

A BrickPi: Protocolo de comunicacion

IndiceA.1. Formato de trama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A.2. Transmision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

A.2.1. Configuracion de los sensores . . . . . . . . . . . . . . . . . . . 61

A.2.2. Actualizacion de los valores . . . . . . . . . . . . . . . . . . . . 62

A.3. Recepcion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

A.4. Tiempos entre tramas . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

En lıneas generales, la comunicacion entre el BrickPi y los sensores y actuadoresdel robot se establace enviando indefinidamente desde la FPGA (o cualquier otro dispositivoexterno conectado) al BrickPi, en un bucle infinito, tramas de datos con un formato especıficoque el firmware de la placa interpreta y envıa las ordenes a traves de los distintos puertos,provocando un efecto en los actuadores conectados, para despues esperar y leer la respuestaenviada por los sensores con la informacion de su estado, que sera devuelta. Antes de entraren el bucle infinito, al principio, se mandan tramas de configuracion indicando el tipo desensor para cada puerto del BrickPi.

La transmision y la recepcion se realizan de forma secuencial, la segunda detrasde la primera. Si la recepcion tardase demasiado tiempo en efectuarse, saltarıa el timeout yse descartarıa. De esta manera, secuencialmente, se asegura que la trama recibida en cada

A. BrickPi: Protocolo de comunicacion

momento sea la que toca, impidiendo la desincronizacion.

A continuacion, se describiran la transmision, la recepcion, los formatos de tramay los posibles valores que cada campo puede tomar.

A.1. Formato de trama

Las tramas, tanto de transmision como de recepcion, se envıan y se reciben me-diante el puerto serie usando los pines GPIO del BrickPi y estan formadas por varios bytesque representan la direccion de destino, una suma de comprobacion, el numero de bytes dedatos que se van a transmitir y los bytes de los datos.

Address Cksum Number of bytes Data[0] Data[1] ... Data[N]

Direccion de destino: El BrickPi tiene dos posibles direcciones (1 y 2), y cada una deellas tiene asociados puertos de sensores y actuadores. La direccion 1 tiene asociadoslos puertos 1 y 2 de los sensores y los A y B de los actuadores; la direccion 2, toma lospuertos 3 y 4 de los sensores y C y D de los actuadores.

Suma de comprobacion: Suma total de los valores de todos los bytes de la trama.

Numero de bytes: Numero de bytes de datos.

Datos: Datos con informacion relativa a los sensores y actuadores.

La numero de datos que se envıan es variable, por eso, la longitud total de la tramatambien es variable.

60

A.2. Transmision

A.2. Transmision

Se pueden transmitir varios tipos de mensajes: de configuracion de los sensores, deconfiguracion de la direccion, de actualizacion de valores, etc. Para indicar de que tipo demensaje se trata, se utiliza el primer byte del vector de datos que se envıa. El valor que esteprimer byte puede tomar y el significado de cada uno se ve reflejado en la Tabla A.2.

Nombre Valor DescripcionMSG TYPE CHANGE ADDR 1 Cambia la direccion de la UART

MSG TYPE SENSOR TYPE 2 Configura el tipo de los sensores

MSG TYPE VALUES 3Actualiza los valores y devuelveinformacion de los sensores

MSG TYPE E STOP 4 Para los motores inmediatamente

MSG TYPE TIMEOUT SETTINGS 5 Cambia el timeout de la recepcion

Tabla A.1: Tipos de mensajes del BrickPi y su identificacion numerica

A la hora de transmitir el mensaje, se le anade al principio de la trama los valoresmencionados en el apartado anterior: direccion de destino, suma de comprobacion y numerode bytes.

A continuacion, se explica como se transmiten algunos de estos mensajes.

A.2.1. Configuracion de los sensores

Como ya se dijo, es necesario mandar al inicio del todo datos de configuracion queindican el tipo de sensor que se hay conectado a cada puerto del BrickPi. Se realiza en unbucle de dos iteraciones, una para cada direccion de destino.

El formato de los datos que se envıan es, en primer lugar, un byte que indica eltipo de mensaje que se esta enviando, y, a continuacion, dos bytes para cada uno de losdos sensores asociados a la direccion de destino. En la Tabla A.2.1 se muestran los valoresnumericos asociados a los distintos tipos de sensores.

61

A. BrickPi: Protocolo de comunicacion

Nombre ValorRaw 0

Light off 0

Light on 9

Touch 32

Ultrasonic cont 33

Ultrasonic SS 34

Color full 36

Color red 37

Color green 38

Color blue 39

Color none 40

Tabla A.2: Valores asociados a cada tipo de sensor

El valor raw o “en crudo” sirve para cualquier tipo de sensor y devuelve un valornumerico entre 0 y 1023. En el valor de contacto (touch), por ejemplo, los posibles valoresdevueltos son 0 y 1, sin embargo, se le puede asignar tambien el tipo raw devolviendo unvalor cercano a 180 (fluctua ligeramente) para el 1 y cercano a 1023 para el 0.

A.2.2. Actualizacion de los valores

La actualizacion de los valores se esta continuamente ejecutando, por cada ejecu-cion se realizan dos iteraciones, una para cada direccion de destino, igual que en la configu-racion de los sensores.

El primer byte de los datos indica el tipo de mensaje, que en este caso es de actua-lizacion de valores y devolucion de informacion de los sensores, con valor numerico 3. Enlos bytes sucesivos se van insertando por conjuntos de bits, desplazandolos para ajustarlos acada byte, los valores de la velocidad de los motores y de habilitacion de los mismos.

62

A.3. Recepcion

A.3. Recepcion

Despues de realizar la transmision de los datos, se espera una respuesta. En casode exceder un determinado lımite de tiempo, se dejarıa de esperar y se descartarıa la tramade vuelta.

Cada mensaje recibido tiene como formato un primer byte de suma de comproba-cion, el segundo byte ındica el numero de bytes, y los siguientes son los datos relevantesrecibidos. El formato es practicamente igual que el de la transmision, salvo por la omisiondel campo de direccion de destino, que ahora no es necesario porque el destino es el mismopara todas las tramas recibidas, el BrickPi.

Cksum Number of bytes Data[0] Data[1] ... Data[N]

En el caso de la configuracion de los sensores, BrickPi espera un byte de confir-macion con valor 1, aparte de la suma de comprobacion y el numero de bytes, que estanpresentes en cada trama recibida.

En la actualizacion de valores, se espera que el primer bytes de los datos sea de tipoMSG TYPE VALUES, de no ser ası, la trama se descartarıa. Ademas, tambien se compruebaque la suma de comprobacion sea correcta, si no lo fuese, tambien se descartarıa. Una vezrealizadas esas comprobaciones, va recorriendo el vector de datos desplazandose medianteun bit offset y extrae los valores de encoder de los motores y los valores del estado de lossensores.

A.4. Tiempos entre tramas

Es importante conocer la diferencia de tiempo entre cada trama de datos enviadaporque, si no, al implementar el protocolo en hardware, los datos se enviaran a una velocidadmucho mayor, por lo que el BrickPi no sera capaz de capturarlos correctamente.

La diferencia temporal entre una trama dirigida a la direccion 1 y otra dirigidaa la direccion 2 (pertenecientes a la misma iteracion), es de aproximadamente 15 ms. Ladiferencia entre la ultima trama de una iteracion (dirigida a la direccion 2) y la primera de lasiguiente iteracion (dirigida a la direccion 1) es de aproximadamente 115 ms.

63

B Plataforma y conexionado

IndiceB.1. FPGA: Virtex-6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

B.2. Pines de expansion de la FPGA . . . . . . . . . . . . . . . . . . . . . . 66

B.3. Conexion entre FPGA y BrickPi: Optoacoplador . . . . . . . . . . . . 69

Los elementos fısicos utilizados para la construccion de la plataforma de prototi-pado los siguientes:

FPGA Xilinx Virtex-6 [Xile] ML605 [Xilf].

Tarjeta de expansion de la Virtex-6 [Xilh].

BrickPi.

Kit de construccion Lego NXT Mindstorms.

2 optoacopladores.

Componentes electronicos: Cables, conectores, circuitos.

Las herramientas software de las que se ha hecho uso son:

B. Plataforma y conexionado

Herramientas ISE 14.5 de Xilinx: XPS, EDK, ChipScope, Coregen, etc.

Vivado HLS 2013.2.

QuestaSim 10.2c.

B.1. FPGA: Virtex-6

La FPGA utilizada ha sido la Virtex-6 ML605 de Xilinx. Los recursos de estaFPGA exceden por mucho las necesidades del proyecto, pero su uso esta destinado principal-mente al prototipado. Una vez implementado el proyecto en su totalidad, se pueden conocerlos recursos realmente necesarios y elegir una FPGA que se ajuste mas a tales necesidades,ası como de dimensiones mas reducidas.

B.2. Pines de expansion de la FPGA

Para acceder a los pines de expansion de la placa, es necesario conectar la tarjeta deexpansion de la Virtex-6. Consultando el esquematico de los pines de dicha tarjeta de expan-sion [Xild] pueden verse los nombres e identificadores de tales pines, lo cual nos servira deguıa al a hora de asignar un pin determinado a una senal. Por ejemplo, para las senales Tx yRx usadas en el proyecto para comunicarse con el BrickPi, se han utilizado los pines J24 yJ25 que se ven en la Figura B.1, extracto del esquematico de la tarjeta de expansion.

Ası, conocemos que los nombres dichos pines son FMC HB01 P y FMC HB01 N,respectivamente. Consultando ahora la guıa de referencia de la FPGA utilizada (ver FiguraB.2) y buscando en ella dichos nombres de pines, se pueden encontrar los nombres utiliza-dos en la FPGA para designar a esos pines. Seran estos nombres, AN32 y AM32, los quehabra que escribir en el fichero de restricciones (UCF, User Constraints File) para asignarlosa las senales de transmision y de recepcion.

66

B.2. Pines de expansion de la FPGA

Figura B.1: Extracto del esquematico de la tarjeta de expansion

67


Figura B.2: Extracto de la guıa de referencia de la Virtex-6

68

B.3. Conexion entre FPGA y BrickPi: Optoacoplador


Para la transmision y recepcion de las senales, es necesario conectar los pines de laFPGA asignados a tales senales con los del BrickPi. Como tanto la FPGA como el BrickPitienen su propia alimentacion electrica, hace falta algun mecanismo que aisle electricamenteambos circuitos como proteccion ante posibles cortocircuitos o cualquier otro tipo de ano-malıa electrica.

Para realizar este aislamiento electrico, se ha hecho uso de unos dispositivos lla-mados optoacopladores, mediante los cuales se obtiene un acoplamiento optico y, al mismotiempo, un aislamiento electrico; por ello, tambien se les conoce como optoaisladores.

Es un dispositivo de emision y recepcion que funciona como un interruptor acti-vado mediante luz emitida por un diodo LED que satura un componente optoelectronico,normalmente en forma de fototransistor. De esta forma, se combinan en un solo dispositivosemiconductor, un fotoemisor y un fotorreceptor cuya conexion entre ambos es optica.

La figura B.3 muestra el esquema general de un optoacoplador. Si la corrienteelectrica que circula por el LED emisor proporciona un nivel de luz adecuado, al incidirsobre el fototransistor, lo saturara generando una corriente en el otro lado.

Figura B.3: Esquema de un optoacoplador

Han sido necesarios dos optoacopladores, uno para la transmision, y otro para larecepcion. El modelo utilizado es NVE IL710-2E [NVE]. Es un optoacoplador de ocho pines,como se muestra en la Figura B.4.

Pin 1: Tension del circuito emisor.

69


Figura B.4: Esquema del optoacoplador NVE IL710

Pin 2: Tension de la senal emitida.

Pin 3: No se conecta.

Pin 4: Se conecta a masa.

Pin 5: Se conecta a masa.

Pin 6: Tension de la senal recibida.

Pin 7: Habilitador de la salida, en este caso no se utiliza.

Pin 8: Tension del circuito receptor.

La Figura B.5 muestra la tabla de verdad del circuito.

Fue necesario soldar un circuito (el que se ve en la Figura B.6) para el conexionadode los dos optoacopladores. El esquema de dicho circuito es el mostrado en la Figura B.7.

70


Figura B.5: Tabla de verdad del optoacoplador NVE IL710

Figura B.6: Soldadura del circuito de los optoacopladores

71


Figura B.7: Esquema del circuito de los optoacopladores

Los conectores del 1 al 8 son los pines de los optoacopladores descritos previamen-te. El optoacoplador superior transmite la senal proveniente de Tx1 desde el circuito numero1 hacia Rx2 en el circuito numero 2. El optoacoplador inferior hace justo lo contrario, trans-mite desde Tx2 en el circuito 2 hacia Rx1 en el circuito 1. Los circuitos 1 y 2 representan alBrickPi y a la FPGA, indistintamente. V 1 y V 2 son la tension de cada circuito, y GND es elconector a masa. El pin 7 de habilitacion de la salida de los dos optoacopladores se conectana tierra ya que no se utilizan.

Las lıneas rojas del dibujo representan las soldaduras de estano sobre el circuito,mientras que las lıneas azules representan conexiones mediante puentes.

A los conectores laterales del esquema se conectan los correspondientes cables quese conectan tambien al BrickPi y a la FPGA. Se han utilizado cables de diferentes colores:

Rojo: Alimentacion.

Negro: Masa o tierra.

72


Amarillo: Transmision.

Azul: Recepcion.

En la Figura B.8 se muestra la vista frontal del circuito con los optoacopladores ylos diferentes cables conectados.

Figura B.8: Vista frontal del circuito de los optoacopladores

73

Referencias

[Dexa] Dexter Industries. Drivers del BrickPi. https://github.com/DexterInd/BrickPi/.

[Dexb] Dexter Industries. Female Sockets for Lego Mindstorms. http://www.

dexterindustries.com/NXTFemaleSockets.html.

[Dexc] Dexter Industries. Firmware del BrickPi. http://www.dexterindustries.com/BrickPi/design/firmware-documentation/.

[Dexd] Dexter Industries. Introduction to BrickPi. http://www.

dexterindustries.com/BrickPi.

[Gas07] Hurbain P. y Hurbain I. Gasperi, M. Extreme NXT. 2007.

[leg] http://mindstorms.lego.com/en-us/Default.aspx.

[Mar] Martin Schoeberl. An FPGA for LEGO MindStorms Roboter. http://www.

jopdesign.com/lego.

[NVE] NVE Corporation. High Speed Digital Coupler IL710 Datasheet.

[Pyt] Python. Pagina web de Python. https://www.python.org/.

[Tex] Texas Instruments. Quadruple Half-H Driver SN754410. http://www.ti.

com/product/sn754410.

[Uni] Universidad de Castilla-La Mancha. Reglamento de procedimiento para la contrata-cion de personal con cargo a proyectos I+D+i con financiacion externa.

[Xila] Xilinx. ChipScope. http://www.xilinx.com/tools/cspro.htm.

[Xilb] Xilinx. Coprocessor. http://www.xilinx.com/support/

documentation/sw_manuals/xilinx14_7/platform_studio/

ps_c_cpw_coprocessor_wizard.htm.

[Xilc] Xilinx. Coregen. http://www.xilinx.com/tools/coregen.htm.

https://github.com/DexterInd/BrickPi/

https://github.com/DexterInd/BrickPi/

http://www.dexterindustries.com/NXTFemaleSockets.html

http://www.dexterindustries.com/NXTFemaleSockets.html

http://www.dexterindustries.com/BrickPi/design/firmware-documentation/

http://www.dexterindustries.com/BrickPi/design/firmware-documentation/

http://www.dexterindustries.com/BrickPi

http://www.dexterindustries.com/BrickPi

http://mindstorms.lego.com/en-us/Default.aspx

http://www.jopdesign.com/lego

http://www.jopdesign.com/lego

https://www.python.org/

http://www.ti.com/product/sn754410

http://www.ti.com/product/sn754410

http://www.xilinx.com/tools/cspro.htm

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/platform_studio/ps_c_cpw_coprocessor_wizard.htm



http://www.xilinx.com/tools/coregen.htm

Referencias

[Xild] Xilinx. Esquematico de la tarjeta de expansion de FPGA Virtex-6.

[Xile] Xilinx. FPGA Virtex-6 Family. http://www.xilinx.com/products/

silicon-devices/fpga/virtex-6/.

[Xilf] Xilinx. Guıa de referencia de Virtex-6 ML605.

[Xilg] Xilinx. MicroBlaze. http://www.xilinx.com/tools/microblaze.

htm.

[Xilh] Xilinx. Tarjeta de expansion de FPGA Virtex-6. http://www.xilinx.com/products/boards-and-kits/HW-FMC-XM105-G.htm.

[Xili] Xilinx. Vivado Design Suite User Guide: High-Level Synthesis.

[Xilj] Xilinx Vivado Design Suite. http://www.xilinx.com/products/

design-tools/vivado/.

[Xil11] Xilinx. AXI Reference Guide, UG761. March 2011.

76

http://www.xilinx.com/products/silicon-devices/fpga/virtex-6/

http://www.xilinx.com/products/silicon-devices/fpga/virtex-6/

http://www.xilinx.com/tools/microblaze.htm

http://www.xilinx.com/tools/microblaze.htm

http://www.xilinx.com/products/boards-and-kits/HW-FMC-XM105-G.htm

http://www.xilinx.com/products/boards-and-kits/HW-FMC-XM105-G.htm

http://www.xilinx.com/products/design-tools/vivado/

http://www.xilinx.com/products/design-tools/vivado/

universidad de castilla la mancha escuela …arco.esi.uclm.es/public/pfc/antonio.ruedas.pdfen...

Documents