¿Qué es este blog?

La idea de este blog nace para compartir los avances que se vayan realizando a lo largo de un estudio sobre cómo interconectar los distintos sensores que se pueden encontrar en el mercado, o fabricar de forma casera, con la plataforma Mindstorms de LEGO. Para ello se hará uso ARDUINO, un entorno de desarrollo abierto basado en microcontrolador.

martes, 30 de noviembre de 2010

¿Cómo maneja LejOS los protocolos I2C y RS-485?

    LejOS permite la ejecución de código escrito en el lenguaje de programación JAVA en el interior del RCX. Incluye un API (Interfaz de Programación de Aplicaciones) que permite tener acceso a los distintos medios de comunicación propios de JAVA, además de a una parte del API estándar del propio lenguaje. LejOS no consta de todas la características de JAVA, pero puede fácilmente evolucionar hacia ellas en un futuro, siempre que la memoria del RCX, por ahora la principal limitación, lo permita

Protocolo I2C mediante LejOS

    Como se ha visto anteriormente, el robot puede comunicarse con los sensores que se le conecten haciendo uso del protocolo I2C. LejOS es capaz de gestionar esta comunicación haciendo uso de una clase denominada I2CSensor, cuyas principales funciones se van a describir a continuación.

    La clase I2CSensor, se encuentra contenida en el paquete Java.Lang.Object de JAVA. En primer lugar se van a ver los tres métodos más usados para nuestros propósitos. Cabe destacar que en todos los casos, si el método devuelve 0 la operación habrá sido un éxito, mientras que si devuelve otra cosa habrá que tratar el error producido.
  • void setAddress(int addr). Establece la dirección del puerto. Es importante destacar que el rango de direcciones que cubre va de 0x01 a 0x7F, y no de 0x02 a 0x7E como se incluye en las especificaciones de algunos dispositivos que funcionan bajo este protocolo.
  • Int sendData(int register, byte value) o Int sendData (int register, byte [ ] buf, int len). Esta instrucción nos va a permitir escribir lo que queramos en el registro del dispositivo seleccionado. En el primer caso, se va a escribir un único byte en el registro I2C deseado, en el segundo caso, se puede especificar la longitud del dato a mandar.
  • Int getData (int register, byte [ ] buf, int len). Es la operación contraria a la anterior. Nos va a permitir obtener el dato que el sensor haya puesto en el registro que indiquemos.

    Otros métodos que también nos van a ser de utilidad son los siguientes:

  • I2CPort GetPort ( ). Es un método que pertenece a la clase I2CPort, contenida dentro del paquete lejos.nxt.BasicSensorPort y más concretamente al paquete lejos.nxt.BasicSensorPort. Nos va a permitir obtener el número de puerto al que está conectado el sensor.
  • String getProductID ( ). Esta función devuelve el identificador de producto del sensor que se esté usando.
  • String getSensorType ( ). Nos va a devolver el tipo de sensor en una cadena, es decir, si es un sensor de temperatura, un sensor de luz, etc.
  • String getVersion ( ). Esta función devolverá, contenida en una cadena, la versión del sensor.

Protocolo RS-485 mediante LejOS

    La clase de LejOS que nos va a permitir tener acceso al protocolo RS-485 es la lejos-nxt.comm.RS485, contenida también dentro del paquete java.lang.objetc, y más conretamente dentro de lejos.nxt.comm.NXTCommDevice. Esta clase proporciona un acceso a bajo nivel a las capas más bajas del hardware que use el protocolo RS-485 y que esté conectado al puerto 4 del NXT. Así mismo, también soporta una conexión de más alto nivel basada en una red de tipo BitBus. Báicamente, la red proporciona una implementación simple de tipo maestro/esclavo usando transmisión de paquetes SDLC (Synchronous Data Link Control) con un control de errores mediante redundancia cíclica CRC-16-CITT. En esta implementación se usa una tasa de transferencia de 921.600 baudios y se usan bytes de lleno en lugar de bits de relleno, como se suele hacer (ya que no hay soporte hardware). El protocolo nos permite realizar hasta  siete conexiones.

    Si bien la implementación original usaba JAVA para el manejo de tramas, se comprobó que se estaba añadiendo una gran tara innecesaria al proceso. Por este motivo, las rutinas de más bajo nivel de implementaron en C y se incluyeron en el firmware como métodos nativos. Así, se consiguió una mejora de un factor de 10 aproximadamente.

    A continuación se van a describir los métodos más importantes para el manejo de este protocolo:
  • Static RS485connection connect (String target). Va a establecer la conexión con un dispositivo remoto mediante el nombre o la dirección, que irán contenida en el parámetro target.
  • Static RS485connection connect (String target, int mode). Es idéntica a la anterior, salvo que nos permite definir el método de entrada/salida que queremos usar.
  • Static void hsDisable ( ). Desactiva el puerto hardware del protocolo RS-485
  • Static void hcEnable ( ). Activa el puerto harware del protocolo RS-485
  • Static int hsRead (byte [ ] buf, int offset, int len). Realiza una lectura de bajo nivel del puerto 4 del Mindstorm. Devuelve el número de bytes leídos.
  • Static int hsWrite (byte [ ] buf, int offset, int len). Realiza una escritura de bajo nivel en el puerto 4 del NXT. Devuelve el número de bytes escritos.
  • Static RS485connection waitForConnection (int timeout, int mode). Espera una conexión de otro NXT. Devuelve el objeto conector.
--------------------------------------------------------------------------------------------------------------------------
Referencias:
  • Sistemas de bus RS-485. http://www.wut.de/e-6wwww-11-apes-000.php
  • Charbel Stockmans Daou (2008). Desarrollo y Evaluación de Aplicaciones Robóticas con Lego Mindstorms. Universidad de Málaga
  • Class I2CSensor (lejos NXJ API Documentation). http://lejos.sourceforge.net/nxt/nxj/api/lejos/nxt/I2CSensor.html#SENSOR_TYPE
  • Class RS485 (lejos NXJ API Documentaion). http://lejos.sourceforge.net/nxt/nxj/api/index.html

Protocolos usados por los Mindstorms en la comunicación (II): RS-485

    El protocolo RS-485, también conocido como EIA-485 es un estándar de comunicaciones en bus de la capa física del modelo OSI.

    Este protocolo se define como un sistema para transmisión multipunto, ideal para transmisión a altas velocidades y a largas distancias (35 Mbps hasta 10 metros y 100 Kbps en 1200 metros) incluso en medios de transmisión ruidosos, ya que reduce los ruidos que aparecen a lo largo de las líneas de transmisión.

    Como medio de transmisión se suele utilizar un par de hilos entrelazados que admite hasta 32 estaciones en un solo hilo con comunicación half-duplex. Se soportan 32 transmisores y 32 receptores. Una de las grandes ventajas de este protocolo es que, al tratarse de un estándar abierto, permite muchas y muy diferentes configuraciones y utilizaciones. En la figura siguiente se puede apreciar un esquema del bus de comunicaciones:

 
    En algunos casos, como en el bus de medición DIN, se puede encontrar un bs de 4 hilos como el que se muestra en la figura inferior. En este caso se cablea la salida de datos del maestro a la entrada de datos de todos los servidores. Las salidas de datos de los servidores están concebidas conjuntamente a la entrada de datos del maestro.


Dado que varios transmisores transmisores trabajan en una línea común, tiene que garantizarse con un protocolo que en todo momento sólo haya activo un transmisor de datos. El resto de transmisores en ese momento deben estar en un estado de alta impedancia para no interferir en la emisión de datos.

    Las principales aplicaciones de este protocolo son:
  • SCSI-2 (Small Computer System Interface) y SCSI-3 usan esta especificación para ejecutar la capa física.
  • Este protocolo se suele usar con frecuencia en las UARTs para comunicaciones de datos de poca velocidad en las cabinas de los aviones. Un ejemplo de ello es su uso en algunas unidades de control de pasajeros. El motivo es que se requiere un cableado mínimo y éste puede ser compartido entre varios asientos, con lo que el sistema resulta simple y de poco peso.
  • Se suele usar también en sistemas grandes de sonido, tales como conciertos, teatros, etc. En los que se controla el sonido desde un ordenador y se envía el sonido a distintos elementos repartidos por la sala.
  • Otro ejemplo de uso de este protocolo es en domótica. Al permitir largas distancias y un cableado simple es idóneo para automatizar distintas partes de un edificio o de una vivienda.

Método físico de transmisión

    Los datos en serie se van a transmitir sin estar referidos a masa, es decir, se envían como la diferencia de tensión entre las líneas correspondientes. Para cada señal a transmitir existe un par de conductores que se compone de una línea de señales invertida y de otra sin invertir.

    La línea invertida suele denominarse “A” y la no invertida “B”, lo que como vimos anteriormente en el caso del Mindstorm corresponde a los pines 5 y 6 respectivamente. El receptor sólo va a evaluar la diferencia de tensión existente entre ambas líneas, de modo que las interferencias comunes a las dos líneas no afectan a la medida.

    Los transmisores ponen a disposición bajo carga un nivel de tensión de ±2V entre las salidas. Los módulos de los receptores reconocen el nivel de ± 200 mV como señal válida.

    La asignación del nivel de tensión diferencial para el estado lógico se define como:

  • A – B <  -0,3 V = MARK = OFF = Nivel lógico ‘1’
  • A – B > +0,3 V = SPACE = ON = Nivel lógico ‘0’
------------------------------------------------------------------------------------------------------------------------
Referencias
  • El protocolo RS-485. http://es.wikipedia.org/wiki/RS-485
  • El modelo de referencia OSI. http://www.eveliux.com/mx/modelo-de-referencia-osi.php
  • Small Computer System Interface. http://es.wikipedia.org/wiki/SCSI
  • Sistemas de bus RS-485. http://www.wut.de/e-6wwww-11-apes-000.php

Protocolos usados por los Mindstorms en la comunicación (I): I2C

   
Introducción

    Bajo estas siglas encontramos uno de los estándares de comunicaciones serie más conocidos en la industria electrónica. I2C es el acrónimo en inglés de Inter-Integrated Circuit, es decir, circuito Inter-Integrado. Atendiendo a esta descripción es fácil imaginar que el objetivo de este bus no será otro que el de interconectar distintos elementos para que pasen a formar parte de un todo. Vamos a describir las principales características de este bus, y lo relacionaremos con los robots de LEGO viendo de qué manera se hace uso del mismo. 

    El bus I2C, un estándar que facilita la comunicación entre microcontroladores, memorias y otros dispositivos con cierto nivel de "inteligencia", sólo requiere de dos líneas de señal y un común o masa.  Fue diseñado a este efecto por Philips y permite el intercambio de información entre muchos dispositivos a una velocidad aceptable, de unos 100 Kbits por segundo, aunque hay casos especiales en los que el reloj llega hasta los 3,4 MHz.

    La metodología de comunicación de datos del bus I2C es en serie y sincrónica. Una de las señales del bus marca el tiempo (pulsos de reloj) y la otra se utiliza para intercambiar datos.

Descripción de las señales

    Dado que es un bus serie, el número de hilos necesarios suele ser ya pequeño de por sí, pero en este caso se ve reducido a sólo 3, de los cuales uno es el cable de masa. El cable de masa puede omitirse en todos aquellos casos en los que hablemos de un único circuito impreso, ya que habitualmente existe una única zona de masa común a todos los componentes. Es una de las principales características de este tipo de bus: menor número de señales implica menor probabilidad de interferencias y una mayor sencillez de cableado en entornos donde el espacio es un factor crítico.

    Los cables usados son los siguientes:

  • SCL (System Clock) es la línea de los pulsos de reloj que sincronizan el sistema.
  • SDA (System Data) es la línea por la que se mueven los datos entre los dispositivos.
  • GND (Masa) común de la interconección entre todos los dispositivos "enganchados" al bus.

     Las líneas SDA y SCL son del tipo drenador abierto, es decir, un estado similar al de colector abierto, pero asociadas a un transistor de efecto de campo (o FET). Se deben polarizar en estado alto (conectando a la alimentación por medio de resistores "pull-up") lo que define una estructura de bus que permite conectar en paralelo múltiples entradas y salidas. Esto se puede ver en la siguiente figura:



    En el diagrama anterior se pueden ver como las dos líneas del bus están en un nivel lógico alto cuando están inactivas. En principio, el número de dispositivos que se puede conectar al bus no tiene límites, aunque hay que observar que la capacidad máxima sumada de todos los dispositivos no supere los 400 pF. El valor de los resistores de polarización no es muy crítico, y puede ir desde 1K8 (1.800 ohms) a 47K (47.000 ohms). Un valor menor de resistencia incrementa el consumo de los integrados pero disminuye la sensibilidad al ruido y mejora el tiempo de los flancos de subida y bajada de las señales. Los valores más comunes en uso son entre 1K8 y 10K.

Protocolo de comunicación del bus I2C

    Un único bus de comunicación I2C puede soportar hasta 128 dispositivos conectados a él directamente. Para poder identificar a los dispositivos, y poder establecer así la comunicación, todos los dispositivos cuentan con una dirección única de 7 bits (de ahí las 128 combinaciones resultantes). Los dispositivos pueden funcionar tanto en modo esclavo como en modo maestro. En cada momento, sólo puede haber un dispositivo en modo maestro en el bus, sin embargo, este dispositivo puede ir cambiando siempre que sus características lo permitan. El maestro es el único autorizado para iniciar el envío de datos, y es también el encargado de generar la señal de reloj. La secuencia de inicio se puede ver en la siguiente figura:

  • La condición inicial, de bus libre se produce cuando ambas señales están en estado lógico alto. En este estado cualquier dispositivo maestro puede ocuparlo, estableciendo la condición de inicio (start). Esta condición se presenta cuando un dispositivo maestro pone en estado bajo la línea de datos (SDA), pero dejando en alto la línea de reloj (SCL).
  • El primer byte que se transmite tras la condición de inicio contiene siete bits que componen la dirección del dispositivo que se desea seleccionar, y un octavo bit que corresponde a la operación que se quiere realizar con él (lectura o escritura).
  • Si el dispositivo cuya dirección corresponde a la que se indica en los siete bits (A0-A6) está presente en el bus, éste contesta con un bit en bajo, ubicado inmediatamente luego del octavo bit que ha enviado el dispositivo maestro. Este bit de reconocimiento (ACK) en bajo le indica al dispositivo maestro que el esclavo reconoce la solicitud y está en condiciones de comunicarse. Aquí la comunicación se establece en firme y comienza el intercambio de información entre los dispositivos.
  • Si el bit de lectura/escritura (R/W) se ha puesto en esta comunicación a nivel lógico bajo (escritura), el dispositivo maestro envía datos al dispositivo esclavo. Esto se mantiene mientras continúe recibiendo señales de reconocimiento, y el contacto concluye cuando se hayan transmitido todos los datos.
  • En el caso contrario, cuando el bit de lectura/escritura estaba a nivel lógico alto (lectura), el dispositivo maestro genera pulsos de reloj para que el dispositivo esclavo pueda enviar los datos. Luego de cada byte recibido el dispositivo maestro (quien está recibiendo los datos) genera un pulso de reconocimiento.
  • El dispositivo maestro puede dejar libre el bus generando una condición de parada (o detención; stop en inglés). Esta secuencia se puede ver en la figura siguiente:
  • Si se desea seguir transmitiendo, el dispositivo maestro puede generar otra condición de inicio en lugar de una condición de parada. Esta nueva condición de inicio se denomina "inicio reiterado" y se puede emplear para direccionar un dispositivo esclavo diferente o para alterar el estado del bit de lectura/escritura.

Direccionamiento de dispositivos en el bus I2C

    Lo más común en los dispositivos para el bus I2C es que utilicen direcciones de 7 bits, aunque existen dispositivos de 10 bits. Este último caso es raro.

    Una dirección de 7 bits implica que se pueden poner hasta 128 dispositivos sobre un bus I2C, ya que un número de 7 bits puede ir desde 0 a 127. Cuando se envían las direcciones de 7 bit, de cualquier modo la transmisión es de 8 bits. El bit extra se utiliza para informarle al dispositivo esclavo si el dispositivo maestro va a escribir o va a leer datos desde él. Si el bit de lectura/escritura (R/W) es cero, el dispositivo maestro está escribiendo en el esclavo. Si el bit es 1 el maestro está leyendo desde el esclavo. La dirección de 7 bit se coloca en los 7 bits más significativos del byte y el bit de lectura/escritura es el bit menos significativo.

    El hecho de colocar la dirección de 7 bits en los 7 bits más significativos del byte produce confusiones entre quienes comienzan a trabajar con este bus. Si, por ejemplo, se desea escribir en la dirección 21 (hexadecimal), en realidad se debe enviar un 42, que es un 21 desplazado un bit hacia arriba. También se pueden tomar las direcciones del bus I2C como direcciones de 8 bit, en las que las pares son de sólo escritura y las impares son de sólo lectura.

Resumen de lectura/Escritura de un dispositivo esclavo

    Para escribir en un dispositivo esclavo, se debe seguir la siguiente secuencia:

1. Enviar una secuencia de inicio
2. Enviar la dirección de dispositivo con el bit de lectura/escritura en bajo
3. Enviar el número de registro interno en el que se desea escribir
4. Enviar el byte de dato
5. [Opcionalmente, enviar más bytes de dato]
6. Enviar la secuencia de parada
Y para leer de un dispositivo esclavo la secuencia es la siguiente:
1. Enviar una secuencia de inicio
2. Enviar 0xC0 (La dirección de dispositivo del CMPS03 con el bit de lectura/escritura en bajo)
3. Enviar 0x01 (dirección interna del registro de ángulo en valor 0-255)
4. Enviar una secuencia de inicio (inicio reiterado)
5. Enviar 0xC1 (La dirección de dispositivo del CMPS03 con el bit de lectura/escritura en alto)
6. Leer un byte de dato desde el CMPS03
7. Enviar la secuencia de parada

Si el esclavo necesita más tiempo

    Esto es todo cuando se trata de comunicaciones simples, pero debemos considerar una posible complicación: Cuando el dispositivo maestro está leyendo desde el esclavo, quien pone los datos en la línea SDA del bus es el dispositivo esclavo, y el maestro es el que controla el pulso de reloj. ¿Qué pasa si el esclavo no está listo para enviar un dato? Con dispositivos como una EEPROMs esto no sería problema, pero si el dispositivo esclavo es un microprocesador, que tiene otras tareas que realizar, pueden surgir inconvenientes.

    Para atender la transacción, el microprocesador debe pasar a una rutina de interrupción, guardar sus registros de trabajo, determinar qué dirección desea leer el dispositivo maestro, obtener el dato y ponerlo en su registro de transmisión. Esto puede llevar varios microsegundos, lo que implica que el dispositivo maestro podría estar enviando pulsos de reloj ciegamente por la línea SCL sin que el dispositivo esclavo pueda responderle. El protocolo I2C ofrece una solución para esto: el esclavo puede mantener la línea SCL en bajo. A esto se le llama estiramiento del reloj. Cuando el esclavo recibe el comando de lectura lo primero que hace es poner la línea de reloj en bajo. Entonces sí, obtiene el dato solicitado, lo pone en el registro de transmisión, y sólo entonces libera la línea de reloj, que pasará de inmediato a nivel alto debido al nivel que aporta el resistor de polarización.

    Desde el punto de vista del dispositivo maestro, éste tratará de enviar el primer pulso de reloj para la lectura de datos liberando la línea SCL para que pase a alto, pero antes de continuar comprobará que ésta realmente haya ido al nivel lógico 1. Si la línea SCL permanece en bajo, el dispositivo maestro interpreta que el esclavo la mantiene así y espera a que SCL vaya a alto antes de continuar. Por suerte, la mayoría de los puertos I2C de los microprocesadores manejan esto de manera automática.

----------------------------------------------------------------------------------------------------------------------

Referencias:
  • Carles Llacer (2009). El bus I2C y LEGO Mindstorms NXT.
  • El bus I2C. http://robots-argentina.com.ar/Comunicacion_busI2C.htm

Estudio de la Entrada/Salida de los Mindstorms

    En este apartado se realiza un estudio de las características de entrada/salida de los Mindstorms de LEGO. Para ello, se verá en primer lugar cómo son físicamente los conectores que permiten al robot interactuar con los sensores, y a continuación (en otro post) se estudiarán los protocolos mediante los cuales se establece la comunicación. Finalmente se verá cómo hacer uso de dichos protocolos usando el lenguaje de programación LejOS (LEGO Java Operating System) y otros lenguajes disponibles.
     
Caracterización física de los puertos de entrada/salida del NXT

    Las conexiones de sensores/actuadores al robot se realizan mediante unos conectores modulares de tipo RJ12 de 6 pines como los que se aprecian en la figura siguiente:


   Estos conectores son compatibles con los conectores de modelos anteriores de LEGO, como el RCX, aunque para ello se debe usar un adaptador.

    Los protocolos que usa el NXT para comunicarse con sus sensores y actuadores son básicamente dos: el protocolo I2C y el protocolo RS-485 que se describirán en el siguiente apartado. Veamos qué función cumple cada uno de los pines del conector anterior: (Hacer click en la imagen para ampliarla)


    Como se puede apreciar en la tabla anterior, los pines 5 y 6 son los que usa el robot para mandar las señales que usarán los protocolos de comunicación, teniendo estas una función u otra según el protocolo usado.

Placa usada para el desarrollo de este trabajo

          Al iniciar esta beca de colaboración se estuvieron estudiando las distintas alternativas que nos ofrece el sistema de desarrollo ARDUINO. Para ello, se tuvieron en cuenta tanto la velocidad de trabajo de los microcontroladores como la capacidad de memoria que ofrecen las placas, ya que ésta última será fundamental a la hora de poder cargar en ella los programas que se elaboren.

          Las dos alternativas que se estuvieron baranjando fueron la denominada Arduino UNO [3] y la placa Arduino Mega con el chip 2560. Esta segunda opción ha sido la que se ha elegido finalmente, ya que se trata de una versión mejorada de la placa Arduino. Está basada en el microcontrolado ATmega 2560, y sus principales características son, tal y como vemos en la tabla anterior, que está dotada con 54 entradas entradas/salidas digitales (de las cuales 14 se puede configurar como salidas PWM), 16 entradas analógicas, un oscilador basado en cristal de cuarzo que oscila a 16 MHz. de frecuencia, conector USB, soporte para ICSP, entrada para conectar un transformador de corriente y un botón de reset.

          La carga de los programas también es rápida ya que el bootloader que incorpora la placa, permite una velocidad de 57600 baudios. A continuación se muestran unas imágenes de dicha placa:

Arduino, ¿Qué es?

          Arduino es una plataforma de hardware libre basada en una sencilla placa de entradas y salidas simple y un entorno de desarrollo que implementa el lenguaje de programación Processing/Wiring. Arduino se puede utilizar para desarrollar objetos interactivos autónomos o puede ser conectado a software del ordenador (por ejemplo: Macromedia Flash, Processing, Max/MSP, Pure Data). Las placas se pueden montar a mano o adquirirse. El entorno de desarrollo integrado libre se puede descargar gratuitamente de la propia página de Arduino.

          Las plataformas Arduino están basadas en los microcontroladores Atmega168, Atmega328, Atmega1280, ATmega8, ATmega2560 y otros similares, chips sencillos y de bajo coste que permiten el desarrollo de múltiples diseños.

          Al ser open-hardware, tanto su diseño como su distribución es libre. Es decir, puede utilizarse libremente para el desarrollo de cualquier tipo de proyecto sin haber adquirido ninguna licencia.


-----------------------------------------------------------------------------------------------------------


          A continuación se detallan algunas características de este sistema de desarrollo. En primer lugar veremos un ejemplo de una posible placa de desarrollo, y a continuación nos centraremos en la que se ha usado para llevar a cabo este trabajo.


Un posible esquema de pines






Entradas y salidas


          El ejemplo que vemos en la figura anterior corresponde a la placa conocida como Diecimila. Consta de 14 entradas digitales configurables entrada i/o salidas que operan a 5 voltios. Cada pin puede proporcionar o recibir como máximo 40 mA. Los pines 3, 5, 6, 8, 10 y 11 pueden proporcionar una salida PWM (Pulse Width Modulation). Si se conecta cualquier cosa a los pines 0 y 1, eso interferirá con la comunicación USB. Diecimila también tiene 6 entradas analógicas que proporcionan una resolución de 10 bits. Por defecto miden de 0 voltios (masa) hasta 5 voltios, aunque es posible cambiar el nivel más alto, utilizando el pin Aref y algún código de bajo nivel.
Elementos con los que podemos interactuar: (tomando como ejemplo la placa USB). Empezando en el sentido de las agujas del reloj desde el centro de la parte superior:

-         Pin de referencia analógica (naranja)
-         Señal de tierra digital (verde claro)
-         Pines digitales 3-13 (verde)
-         Pines digitales 1-2 / entrada y salida del puerto serie: TX/RX (azul) (estándar de comunicación 
           serie IC2)
-         Botón de reset (negro)
-         Entrada del circuito del programador serie (marrón)
-         Pines de entrada analógica 0-5 (azul oscuro)
-         Pines de alimentación y tierra (naranja y naranja claro)
-         Entrada de la fuente de alimentación externa (9-12V DC) – X1 (gris)
-         Conmutación entre fuente de alimentación externa o alimentación a través del puerto USB–SV1


  -----------------------------------------------------------------------------------------------------------


          A continuación se muestra una tabla que contiene los distintos microcontroladores que se incluyen en las placas usadas por ARDUINO, junto con sus principales características. (Haced click en la imagen para ampliarla)


lunes, 29 de noviembre de 2010

Video tutoriales sobre Arduino

Una imagen vale más que mil palabras, y un vídeo mucho más aún :) Algunos videotutoriales que he encontrado sobre Arduino (simplemente para empezar a entenderlo).







LEGO Mindstorms

Para desarrollar este trabajo se ha usado el último modelo de LEGO Mindstorm disponible en el mercado, el NXT. Estásta formado por un kit que incluye: el ladrillo NXT, múltiples sensores (luz/color, ultrasonidos, contacto, sonido), motores y cableado eléctrico, y el set de construcción habitual de la línea Technic, formado por miles de piezas entre ellas juegos de engranajes y poleas para conectar a los motores. En la siguiente figura se ve el NXT con algunos de los sensores y actuadores disponibles para el mismo:
 A continuación se presenta una lista de las características electrónicas del NXT, que se han extraído del manual de LEGO:
                           
-                     El procesador principal es el ARM de Atmel AT91SAM7S256 cuyas principales características son:
o   Es un procesador de 32 bits
o   Incorpora 256 Kb de memoria Flash
o   Tiene 64 Kb de memoria RAM
o   Funciona a 48 Mhz.
-                     El robot lleva también un coprocesador AVR de Atmel, modelo  ATmega48 que tiene:
o   4 Kb de memoria Flash
o   512 Bytes de RAM
o   Funciona a 8 Mhz.
-                     El robot es capaz de mantener conexiones Bluetooh gracias a una unidad de comunicaciones formada por un módulo CSR BlueCoreTM 4 v2.0 con sistema EDR. Sus características son:
o   Soporta Perfiles por Puerto Serie (SPP)
o   Tiene 47 KBytes de memoria RAM interna
o   Contiene 8 Mb de memoria FLASH externos
o   Trabaja a 26 MHz.
-                     Se puede comunicar con el PC también mediante USB 2.0, funcionando a 12 Mbits/s
-                     Existen 4 puertos de entrada con interfaz de 6 hilos, tal y como se describirá en los subsiguientes apartados.
o   Todos los puertos de salida soportan el protocolo I2C
o   Uno de los puertos es de alta velocidad: IEC 61158 tipo 4/EN 50170 compatible.
-                     Existen 3 puertos de salida con interfaz de 6 hilos y soporte para lectura de codificadores
-                     En el centro del robot se encuentra un display gráfico LCD de 100x64 pixeles (en blanco y negro).
-                     El altavoz de salida del robot tiene una resolución de 8 bits, y soporta tasas de muestreo de 2 a 16 KHz.
-                     El usuario puede interactuar con el robot mediante 4 botones de goma
-                     La alimentación del robot se puede hacer mediante 6 pilas alcalinas de tipo AA, o bien mediante una batería de Ion Litio de 1400 mAH, siendo esta última opción la que nosotros hemos usado.
-                     Los conectores de 6 hilos son estándar industrial, de tipo RJ12 con ajuste a derechas.

Fases del trabajo

  1. Estudio de la E/S del robot. Se recabará toda la información disponible en la literatura y se elaborará un informe final que permita conocer las características completas de las entradas sensoriales del robot, incluyendo el acceso a las mismas en diferentes lenguajes de programación del NXT (NXC y LejOS).
  2. Determinación de la funcionalidad necesaria para conectar sensores simples al NXT: tipos de entradas, características de alimentación, …).
  3. Determinación de la funcionalidad necesaria para conectar sensores complejos al NXT.
  4. Diseño de un interfaz hardware, lo más genérico posible, que permita conectar al NXT diferentes tipos de sensores. Será necesario evaluar la posibilidad de usar sistemas basados en microcontroladores comerciales (PIC) o abiertos (Arduino), y establecer toda la circuitería correspondiente.
  5. Implantación del interfaz.
  6. Pruebas reales con un NXT y diferentes tipos de sensores

Objetivos de este trabajo

Los objetivos de este trabajo son los siguientes:

     - Obtener una caracterización completa de la entrada sensorial de los robots LEGO Mindstorms NXT.

     - Analizar las posibilidades de implantación de un interfaz hardware que permita conectar al NXT sensores personalizados simples (por ejemplo, pasivos) o complejos (por ejemplo, sensores láser de distancia)

     - Diseñar un sistema de interfaz entre un NXT y sensores personalizados que sea lo más genérico posible y pueda abarcar tanto sensores simples como sensores más complejos.