Archivo de la categoría: Arduino

Descripción y funcionamiento del Bus I2C

Introducción

DEFINICIÓN DE I2C (I2C): Abreviatura de Inter-IC (inter integrated circuits), un tipo de bus diseñado por Philips Semiconductors a principios de los 80s, que se utiliza para conectar circuitos integrados (ICs). El I2C es un bus con múltiples maestros, lo que significa que se pueden conectar varios chips al mismo bus y que todos ellos pueden actuar como maestro, sólo con iniciar la transferencia de datos. Este bus se utiliza dentro de una misma placa de un dispositivo.

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

  • 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 interconexión entre todos los dispositivos «enganchados» al bus.

Las líneas SDA y SCL son del tipo drenaje 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.

El diagrama es suficientemente autoexplicativo. 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

Habiendo varios dispositivos conectados sobre el bus, es lógico que para establecer una comunicación a través de él se deba respetar un protocolo. Digamos, en primer lugar, lo más importante: existen dispositivos maestros y dispositivos esclavos. Sólo los dispositivos maestros pueden iniciar una comunicación.

La condición inicial, de bus libre, es 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 luego de 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) fue 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).

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.

Definición de términos:

  • Maestro (Master): Dispositivo que determina los tiempos y la dirección del tráfico en el bus. Es el único que aplica los pulsos de reloj en la línea SCL. Cuando se conectan varios dispositivos maestros a un mismo bus la configuración obtenida se denomina «multi-maestro».
  • Esclavo (Slave): Todo dispositivo conectado al bus que no tiene la capacidad de generar pulsos de reloj. Los dispositivos esclavos reciben señales de comando y de reloj generados desde el maestro.
  • Bus libre (Bus Free): Estado en el que ambas líneas (SDA y SCL) están inactivas, presentando un estado lógico alto. Es el único momento en que un dispositivo maestro puede comenzar a hacer uso del bus.
  • Comienzo (Start): Se produce cuando un dispositivo maestro ocupa el bus, generando la condición. La línea de datos (SDA) toma un estado bajo mientras que la línea de reloj (SCL) permanece alta.
  • Parada (Stop): Un dispositivo maestro puede generar esta condición, dejando libre el bus. La línea de datos y la de reloj toman un estado lógico alto.
  • Dato válido (Valid Data): Situación presente cuando un dato presente en la línea SDA es estable al tiempo que la línea SCL está a nivel lógico alto.
  • Formato de Datos (Data Format): La transmisión de un dato a través de este bus consiste de 8 bits de dato (1 byte). A cada byte transmitido al bus le sigue un noveno pulso de reloj durante el cual el dispositivo receptor del byte debe generar un pulso de reconocimiento.
  • Reconocimiento (Acknowledge): El pulso de reconocimiento, conocido como ACK (del inglés Acknowledge), se logra colocando la línea de datos a un nivel lógico bajo durante el transcurso del noveno pulso de reloj.
  • Dirección (Address): Todo dispositivo diseñado para funcionar en este bus posee su propia y única dirección de acceso, preestablecida por el fabricante. Hay dispositivos que permiten definir externamente parte de la dirección de acceso, lo que habilita que se pueda conectar en un mismo bus un conjunto de dispositivos del mismo tipo, sin problemas de identificación. La dirección 00 es la denominada «de acceso general»; a ésta responden todos los dispositivos conectados al bus.
  • Lectura/Escritura (Bit R/W): Cada dispositivo tiene una dirección de 7 bits. El octavo bit (el menos significativo) que se envía durante la operación de direccionamiento, completando el byte, indica el tipo de operación a realizar. Si este bit es alto el dispositivo maestro lee información proveniente de un dispositivo esclavo. Si este bit es bajo, el dispositivo maestro escribe información en un dispositivo esclavo.

La comunicación en más detalle

Cuando el dispositivo maestro quiere comunicarse con un esclavo, produce una secuencia de inicio en el bus. La secuencia de inicio es una de las dos secuencias especiales que se han definido en el bus I2C; la otra es la secuencia de parada. Las secuencias de inicio y la de parada son especiales porque son los dos únicos casos en que se permite que la línea de datos (SDA) cambie cuando la línea de reloj (SCL) está alta. Cuando se están transmitiendo datos, la línea SDA debe permanecer estable, y jamás cambiar, mientras la línea SCL está alta. Las secuencias de inicio y de parada señalan el comienzo y el final de una transacción con los dispositivos esclavos.

Los datos se transfieren en secuencias de 8 bits. Estos bits se colocan en la línea SDA comenzando por el bit de más peso (o más significativo). Una vez puesto un bit en SDA, se lleva la línea SCL a alto. Debemos recordar que el chip no puede llevar la línea a un estado alto, en realidad, lo que hace es «soltarla», y el que la pone en nivel lógico alto es el resistor de polarización. Por cada 8 bits que se transfieren, el dispositivo que recibe el dato envía de regreso un bit de reconocimiento, de modo que en realidad por cada byte de dato se producen 9 pulsos sobre la línea SCL (es decir, 9 pulsos de reloj por cada 8 bits de dato). Si el dispositivo que recibe envía un bit de reconocimiento bajo, indica que ha recibido el dato y que está listo para aceptar otro byte. Si retorna un alto, lo que indica es que no puede recibir más datos y el dispositivo maestro debería terminar la transferencia enviando una secuencia de parada.

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 bist 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. Para dar un ejemplo, el integrado de brújula magnética CMPS03 es fijado en fábrica en la dirección 0xC0 ($C0). La dirección 0xC0 se utiliza para escribir en él y la dirección 0xC1 es para leer de él.

Protocolo de programación para el bus I2C

Lo primero que ocurre en un bus I2C es que el dispositivo maestro envía una secuencia de inicio. Esto alerta a los dispositivos esclavos, poniéndolos a la espera de una transacción. Éstos quedan atentos para ver si se trata de una solicitud para ellos. A continuación el dispositivo maestro envía la dirección de dispositivo. El dispositivo esclavo que posee esa dirección continuará con la transacción, y los otros ignorarán el resto de los intercambios, esperando la próxima secuencia de inicio.

Habiendo direccionado ya el dispositivo esclavo, lo que debe hacer ahora el maestro es enviar la ubicación interna o número de registro desde el que desea leer o al que va a escribir. La cantidad depende, obviamente, de qué dispositivo es y de cuántos registros internos posee. Algunos dispositivos muy simples no tienen ninguno, pero la mayoría sí los poseen.

Siguiendo con el ejemplo del CMPS03, éste posee 16 ubicaciones internas, numeradas desde el 0 al 15. Otro dispositivo, el medidor ultrasónico de distancia SRF08, tiene 36 registros.

Una vez que el maestro ha enviado la dirección del dispositivo en el bus I2C y la dirección del registro interno del dispositivo, puede enviar ahora el byte o bytes de datos. El dispositivo maestro puede seguir enviando bytes al esclavo, que normalmente serán puestos en registros con direcciones sucesivas, ya que el esclavo incrementa automáticamente la dirección del registro interno después de recibir cada byte. Cuando el maestro ha terminado de escribir datos en el esclavo, envía una secuencia de parada que concluye la transacción.

Escritura en un dispositivo esclavo:

  • 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

Como ejemplo, veamos un SRF08, que tiene una dirección de bus fijada en fábrica de 0xE0. Para comenzar una medición de distancia con el SRF08 se debe escribir 0x51 en el registro de comando, ubicado en la dirección interna 0x00. La secuencia es la que sigue:

  • 1. Enviar una secuencia de inicio
  • 2. Enviar 0xE0 (La dirección de dispositivo del SRF08 con el bit de lectura/escritura en bajo)
  • 3. Enviar 0x00 (dirección interna del registro de comando)
  • 4. Enviar 0x51 (el comando para comenzar la medición del SRF08)
  • 5. Enviar la secuencia de parada

Lectura desde un dispositivo esclavo:

Esta operación es algo más complicada, pero no demasiado. Antes de leer datos desde el dispositivo esclavo, primero se le debe informar desde cuál de sus direcciones internas se va a leer. De manera que una lectura desde un dispositivo esclavo en realidad comienza con una operación de escritura en él. Es igual a cuando se desea escribir en él: Se envía la secuencia de inicio, la dirección de dispositivo con el bit de lectura/escritura en bajo y el registro interno desde el que se desea leer. Ahora se envía otra secuencia de inicio nuevamente con la dirección de dispositivo, pero esta vez con el bit de lectura/escritura en alto. Luego se leen todos los bytes necesarios y se termina la transacción con una secuencia de parada.

Volviendo al ejemplo del módulo de brújula CMPS03, veamos cómo se lee el registro de ángulo:

  • 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

La secuencia se verá así:


Un caso un poco más complicado

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 recién entonces libera la línea de reloj, que pasará de inmediato a 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.

Sin embargo, a veces el manejo de I2C en el dispositivo maestro no está implementado por circuito, sino que es un juego de subrutinas que maneja dos líneas de un puerto. Algunas implementaciones ignoran este estiramiento del reloj. Estas soluciones trabajarán bien con dispositivos tales como las EEPROM, pero no podrán intercambiar datos correctamente con microprocesadores esclavos que utilizan el estiramiento del pulso de reloj. Como resultado, se obtendrán datos erróneos.

Especificaciones de Philips sobre el bus I2C (PDF)



Control de motores de CC por Ancho de Pulso (PWM)

La Regulación por Ancho de Pulso de un motor de CC está basada en el hecho de que si se recorta la CC de alimentación en forma de una onda cuadrada, la energía que recibe el motor disminuirá de manera proporcional a la relación entre la parte alta (habilita corriente) y baja (cero corriente) del ciclo de la onda cuadrada. Controlando esta relación se logra variar la velocidad del motor de una manera bastante aceptable.

El circuito que se ve a continuación es un ejemplo de un control de Regulación de Ancho de Pulso (PWM, Pulse-Width-Modulated en inglés), que se podría adaptar al circuito de un Puente H (Puente H: Circuito para controlar motores de corriente continua. El nombre se refiere a la posición en que quedan los transistores en el diagrama del circuito).

El primer circuito —con el MOSFET de potencia BUZ11— permite controlar motores medianos y grandes, hasta 10 A de corriente. El segundo circuito —con el transistor 2N2222A— es para motores pequeños, que produzcan una carga de hasta 800 mA.

El que sigue es un circuito genérico de generación de pulsos que se puede utilizar en aquellos lugares donde sea necesario un pulso digital no demasiado preciso. Cambiando los valores de R1 y R2 se ajusta la frecuencia básica. El potenciómetro regula el ancho de pulso.

A continuación, el circuito básico y la fórmula para calcular los anchos de pulso generados por el integrado 555.

Completando la información básica, debemos saber que la mayoría de los microcontroladores poseen generadores de ancho de pulso modulado para control de velocidad de motores y otros controles de potencia digitales, como el brillo de un led o de una lámpara. En las salidas digitales del Arduino UNO se identifica la capacidad PWM con un símbolo ~. En el Arduino UNO los pines 3, 5, 6, 9, 10 y 11 tienen capacidad de salida de pulsos digitales con ancho modulado:

En estos módulos PWM de los microcontroladores, la proporción de tiempo que está encendida la señal respecto al total del ciclo se denomina “Duty cycle”, y generalmente se expresa en tanto por ciento.

La señal promedio es el producto de la tensión máxima y el valor Duty Cycle. La expresión para el cálculo es:

De forma similar, tenemos que

La «salidas analógicas» NO lo son

Debemos tener presente que en una salida PWM el valor de tensión en realidad es Vcc. Por ejemplo, si estamos alimentando un dispositivo que requiere 3V, y usamos una señal pulsada, en realidad estaremos suministrando 5V durante un 60% del tiempo y 0V durante el 40%. Pero si el dispositivo tiene alguna característica por la cual soporta como máximo 3V, podemos dañarlo si lo alimentamos mediante una señal PWM de estas características.

La señal pulsada es buena para emular una señal analógica en muchas aplicaciones. Podemos, por ejemplo, variar la intensidad luminosa en un LED. Éste realmente se enciende y apaga varias veces por segundo, pero el parpadeo es tan rápido que el ojo no lo aprecia. El efecto percibido es que el LED brilla con menor intensidad.

Otro ejemplo es que al variar la velocidad de un motor DC con un PWM, en la mayoría de los casos la inercia del motor se encargará de que el efecto de los cortes de señal sean despreciables. No obstante, dependiendo de la frecuencia utilizada, podemos notar vibraciones o ruidos, lo que implica que deberemos variar la frecuencia del ciclo PWM.

También es importante tener en cuenta aquellos efectos que la rápida conexión y desconexión de la señal pulsada pueden producir en el dispositivo que se alimenta. En el caso de cargas inductivas (motores, relés, o electroimanes), la desconexión producirá una generación de contracorriente que puede dañar la salida digital, o al dispositivo, por lo que será necesario implementar una protección.

Control de ancho de pulso en Arduino

■ En Arduino Uno, Mini y Nano existen 6 salidas PWM de 8 bits en los pines 3, 5, 6, 9, 10 y 11.

■ En Arduino Mega existen 15 salidas PWM de 8 bits en los pines 2 a 13 y 44 a 46

■ En Arduino Due existen 13 salidas PWM de 8 bits en los pins 2 a 13. Adicionalmente, esta placa incorpora dos salidas analógicas con resolución de 12 bits (4096 niveles)

Una resolución de 8 bits en una salida PWM significa que tiene 256 niveles. Es decir, el Duty cycle se divide en 256 posiciones posibles.





Timers en Arduino

Las funciones PWM que son controladas por hardware emplean los módulos Timer para generar la onda de salida. Cada Timer queda afectado a 2 o 3 salidas PWM.

Cada salida conectada a un mismo temporizador comparte la misma frecuencia, aunque pueden tener distintos Duty cycles, dependiendo de un valor en su registro de comparación.

En el Arduino Uno, Mini y Nano el uso de timers es:

■ El Timer0 controla las salidas PWM 5 y 6. El Timer1 controla las salidas PWM 9 y 10. El Timer2 controla las salidas PWM 3 y 11.

En el Arduino Mega el uso es:

■ El Timer0 controla las salidas PWM 4 y 13. El Timer1 controla las salidas PWM 11 y 12. El Timer2 controla las salidas PWM 9 y 10. El Timer3 controla las salidas PWM 2, 3 y 5. El Timer4 controla las salidas PWM 6, 7 y 8.
El Timer5 controla las salidas PWM 44, 45 y 46.

Frecuencia de ciclo de PWM

La frecuencia de cada PWM depende de las características del temporizador al que está conectado, y de un registro de pre-escala, que divide el tiempo por un número entero. La frecuencia de los PWM se puede modificar cambiando la pre-escala de los Timer correspondientes.

Arduino Uno, Mini y Nano disponen de tres temporizadores.

■ Timer0, con una frecuencia de 62.500 Hz, y pre-escala de 1, 8, 64, 256 y 1024.
■ Timer1, con una frecuencia de 31.250 Hz, y pre-escala de 1, 8, 64, 256, y 1024.
■ Timer2, con una frecuencia de 31.250 Hz, y pre-escala de 1, 8, 32, 64, 128, 256, y 1024.

El Arduino Mega añade tres temporizadores adicionales.

Timer3, 4 y 5, con una frecuencia de 31.250 Hz, y pre-escala de 1, 8, 64, 256 y 1024.

Por esto, la frecuencia estándar para las salidas PWM en Arduino Uno, Mini y Nano es de 490 Hz para todos los pines, excepto para el 5 y 6 cuya frecuencia es de 980 Hz. En el Arduino Mega, la frecuencia estándar es de 490 Hz para todos los pines, excepto para el 4 y 13 cuya frecuencia es de 980 Hz

Incompatibilidades:

El uso de los Timer no es exclusivo para las salidas PWM: es compartido con otras funciones. Emplear funciones que requieren el uso de estos Timer supondrá que no podremos emplear al mismo tiempo alguno de los pines PWM.

Algunas de las incompatibilidades más típicas:

1. La librería servo hace uso intensivo de temporizadores por lo que, mientras la estemos usando, no podremos usar algunas de las salidas PWM.

En el caso de Arduino Uno, Mini y Nano, la librería servo usa el Timer 1, por lo que no podremos usar los pines 9 y 10 mientras tengamos un servo en el crcuito.

En el caso de Arduino Mega, dependerá de la cantidad de servos que empleemos.

Si usamos menos de 12 servos el Mega utiliza el Timer 5, por lo que no se pueden usar para PWM los pines 44, 45 y 46. Para 24 servos usa los Timer 1 y 5, por lo que no se pueden usar para PWM los pines 11, 12, 44, 45 y 45. Para 36 servos usa los Timer 1, 3 y 5, impidiendo usar para PWM los pines 2, 3, 5, 11, 12, 44, 45, 46. Para 48 servos, usa los Timer 1, 3, 4 y 5, quedando sin pines PWM disponibles.

2. SPI: en Arduino Uno, Mini y Nano, el pin 11 se emplea también para la función MOSI de la comunicación SPI. Por lo cual no podremos usar ambas funciones de ese pin en forma simultánea. Arduino Mega no tiene este problema, ya que se conectan a pines distintos.

3. La función Tone emplea el Timer 2, por lo que no podremos usar los pines 3 y 11 para PWM. En Arduino Mega no se pueden usar los pines 9 y 10.

En todos los casos, todo se debe al uso de bibliotecas (librerías) de funciones. Programando en muy bajo nivel, es posible lograr mejores prestaciones. Pero no es una tarea fácil, ya que requiere mucha experiencia.

Artículos relacionados:
Uso de la placa L298N para motores de CC
Puente H: Placa controladora de motores L9110S
Guía rápida de placas de control de motores
Manejo de potencia para motores con el integrado L293D
Control de motores de CC por Ancho de Pulso (PWM)


Pez robot se mueve alimentado con “sangre” falsa

La historia comienza a centenares de metros de altura con las aves migratorias, y termina con un pez robótico nadando en el agua debajo. Para prepararse para sus viajes, las aves engordan mucho, hasta casi duplicar su peso, lo que las convierte en baterías emplumadas. Queman esa reserva de energía para impulsar sus alas a lo largo de muchos días y muchos kilómetros, y para evitar morir de hambre y congelarse. Finalmente, llegan extenuadas a sus destinos.

Una buena idea, pensaron los ingenieros de Cornell y de la Universidad de Pennsylvania, para un nuevo sistema de alimentación de potencia para máquinas. Les hizo pensar: la grasa es una batería genial, pero no es muy factible replicarla en un robot. ¿Pero… y la sangre? En un ser humano, la sangre distribuye oxígeno y energía para las células en todo el cuerpo. Y algunos robots, ya se mueven en base a fluidos, en forma de hidráulica. Entonces, ¿por qué no modificar ese fluido para transportar energía, ya que nuestra sangre alimenta nuestros músculos?

A lo que han llegado no es un ave robot (demasiado complicada y con intensa necesidad de energía) sino a un pez león robot que utiliza un sistema vascular rudimentario y «sangre» para energizarse y alimentar hidráulicamente sus aletas. Esta tecnología aún está en sus primeros días, y de hecho este pez es extremadamente lento, pero quizás algunas máquinas del mañana podrían deshacerse de las baterías y los cables y alimentarse como organismos biológicos.

Inflexiblemente, los robots actuales están segmentados. Tienen una batería de iones de litio, que distribuye la energía por medio de cables a los motores de sus extremidades, a los que se conoce como actuadores. Este nuevo pez león robótico tiene baterías, pero están esparcidas por todo su cuerpo y funcionan en conjunto con dos bombas, una para alimentar las aletas pectorales y otra para la cola. Juntas, las baterías y las bombas actúan más como corazones biológicos que como una batería de ion litio en un robot tradicional.

El primer componente es la «sangre», en esencia un fluido hidráulico cargado con iones disueltos, lo que le da potencial químico para alimentar la electrónica. «El fluido hidráulico transmite fuerza, y solo fuerza», dice Robert Shepherd, el robotista de Cornell, coautor de un nuevo artículo en Nature que describe el sistema. «En nuestro fluido, estamos transmitiendo fuerza y estamos transmitiendo energía eléctrica».




Este líquido cargado fluye a través de las células de la batería en el abdomen y las aletas del pez. Cada celda tiene dos piezas de metal opuestas: un cátodo y un ánodo. A medida que el fluido fluye más allá de estos, crea un desequilibrio de carga o voltaje que hace que los electrones fluyan a través de la electrónica que alimenta las dos bombas. Estos a su vez mantienen el bombeo del fluido. Finalmente las celdas de la batería se agotarán, ya que el líquido pierde iones y dejará de circular. En ese momento es posible recargar el líquido para que los peces sigan funcionando. «En realidad, podrían drenar el fluido e inyectar más fluido cargado», dice Shepherd, «algo así como llenar su tanque de combustible en la estación de servicio».

El fluido, entonces, energiza a los peces. Pero también actúa como un fluido hidráulico tradicional, ya que transmite fuerza a la cola y las aletas pectorales. Cuando las bombas empujan el fluido hacia las aletas, se doblan hacia atrás y hacia delante para impulsar el robot. Las aletas pectorales funcionan de la misma manera para guiar a los peces hacia la izquierda y hacia la derecha.

Esto no mueve al robot de manera particularmente rápida: los peces pueden cubrir aproximadamente 1,5 veces la longitud de su cuerpo por minuto. «Definitivamente se lo comerían si estuviera en el océano», dice Shepherd.

Pero la velocidad del robot mejorará, ya que Shepherd y su equipo pueden aumentar el área de superficie de los ánodos y cátodos para mejorar la densidad de potencia. A diferencia de un robot tradicional de cuerpo duro, pueden llenar con celdas de batería donde lo deseen y dejar que la forma blanda del robot se adapte a los componentes adicionales. De este modo, se construye un sistema circulatorio robótico extendido: bombas y baterías que transportan el líquido por todo el robot.

Este sistema tiene algunas limitaciones importantes, especialmente teniendo en cuenta el estado avanzado de la tecnología de iones de litio. «La densidad de potencia es de 30 a 150 veces menos en lo que se observa en comparación con la capacidad de una batería de ión litio», dice el robotista del MIT CSAIL Robert Katzschmann, cuyo pez robot utiliza una batería de ión litio tradicional. Eso significa que el robot de Katzschmann puede moverse 20 veces más rápido que este nuevo pez.

Además, la naturaleza distribuida de este nuevo sistema de energía en los peces implica que no es posible cambiar con facilidad una batería sobre la marcha. «Cada vez que iba al océano, simplemente reemplazaba la batería por una nueva, así que no tengo que esperar para recargar mi prototipo», dice Katzschmann.

Aún así, podría haber un lugar para esta nueva visión de la robótica, junto con los sistemas tradicionales de iones de litio. Hay un montón de peces en el mar, después de todo.



Advertencia sobre los motores con reducción en el Mercado

Atención a los que compran, sea en Argentina o afuera, motores con reducción como el de la foto.

Motor chino con rueda de gomaMotor con reductor de velocidad

Hay una tanda más barata -y posiblemente sean los que más están llegando ahora a Argentina- de motores que consumen UNA ENORMIDAD de corriente. Más o menos el TRIPLE que los que se vienen en Kit junto con las bases robóticas de acrílico. Se ven idénticos a los otros, pero se nota la diferencia al mover la rueda con la mano

Pero el problema mayor es que el engranaje reductor de estos nuevos motores es mucho más pesado que el los otros, de modo que al arrancar los motores producen un pico de corriente de 800 mA mínimo.

Algunos circuitos simples de robots con salida a transistores que utilizan, por ejemplo, PN2222A o su equivalente 2N2222A, no soportan esta corriente. (Solamente los transistores de este tipo marca Fairchild indican en su hoja de datos que soportan 1A; las otras marcas indican 600 mA a 800 mA los mejores.)

Busquen siempre que el vendedor ponga en su publicación una hoja de datos que liste CLARAMENTE el consumo de corriente a los distintos voltajes: 3V, 6V, etc. como la que pongo en la imagen.

Hoja de datos de un motorHoja de datos de un motor

O al menos lleven un tester para medir corriente y un portapilas de 4 pilas con pilas cargadas y cableen para probar el consumo del motor antes de comprar. Es muy útil llevar ya preparado un circuito ya armado con pincitas/clips de prueba ya preparadas para conectar al motor y al tester (si son pinzas «cocodrilo» que sean pequeñas: los contactos del motor son muy débiles).

Distintos clips y pinzas para pruebas electrónicasClips y pinzaas




Walbi, el bípedo que aprende a caminar

Conozca a Walbi, un humanoide a escala 50% con programas Arduino para captura y reproducción de movimiento. Se mueve a mano, graba y reproduce luego los movimientos. El WALink BIped es un robot creado por Pedro y Gil Tavares, de Lisboa, para un proyecto de aprendizaje automático que no se concretó.

Walbi usa un Arduino Nano como «cerebro», servos LX-16A de «músculos», y partes plásticas impresas en 3D como «huesos». Los servos LewanSoul LX-16A son servos ideales para pequeños proyectos robóticos, ya que son livianos, pueden mover cargas de más de 19 kg/cm, y se conectan con un solo cable que va de servo a servo, lo que hace que el cableado del robot sea un juego de niños.

Walbi es un humanoide a escala 50%: sus piernas miden 55 cm de altura desde el talón hasta la cintura, y pesan 1,1 kg. Las partes blancas de su cuerpo fueron impresas en 3D, pero podrían haberse hecho fácilmente con madera resistente y liviana.

La programación de Walbi es muy sencilla. Usted puede descargar los dos programas necesarios para realizar la captura y reproducción de movimientos, y entonces puede hacer que Walbi camine, se arrastre, suba, salte o baile. Solo tiene que mover sus piernas a una postura deseada, registrar esa postura, darle forma a Walbi en otra postura, grabarla y así sucesivamente, y luego, cuando haya grabado la secuencia completa, puede sentarse y ver cómo se desempeña hábilmente siguiendo los movimientos que aprendió.

Qué se necesita

Componentes de hardware (sí, siempre hay que comprar algunas cosas):

Aplicaciones de software y/o servicios en línea: Arduino IDE

Herramientas manuales y máquinas de fabricación: Impresora 3D (genérica)

Construyendo a Walbi

Las piezas de Walbi se imprimieron en 3D, con plástico PLA, utilizando una impresora FlashForge Creator Pro. Descargar los archivos STL de Thingiverse, o usar un método alternativo para construir los pies, los “huesos” de las piernas y la cintura, utilizando madera o metal. Los soportes de los servos encajan en estas partes, y unen los servos con ellas.

Como se muestra en el dibujo de abajo, necesitará soportes metálicos de los cuatro tipos diferentes disponibles para adjuntar los servos a las partes impresas, y entre sí.

Conexionado

Para controlar los servos LX-16A se necesita una placa de LewanSoul llamada Bus Linker.

Ésta recibirá comandos desde un puerto serie en el Arduino Nano. Como utilizamos la USART del hardware de Arduino para comunicarnos con la computadora, recurrimos a la biblioteca SoftwareSerial para crear un segundo puerto serie en el Nano, que nos sirve para conectarnos a la placa Bus Linker.

El cableado se minimiza con estos servos serie. Hay un cable que va de cada servo al siguiente (un cable serie provisto con los servos) y los servos se enchufan directamente a la placa de depuración. Su computadora se conecta al puerto USB de Arduino, y Arduino se conecta a la placa de depuración mediante tres cables (TX, RX y GND) conectados a los pines de Arduino que fueron configurados para SoftwareSerial.

Los servos utilizan una velocidad de comunicación serie en baudios de 115200 (que es demasiado alto y falta investigar si se modificar). Esta velocidad en baudios es alta para SoftwareSerial, por lo que tuvimos que implementar funciones de comprobación de errores y reintento. En algunos casos se necesitaba persistencia para obtener una lectura correcta.

Fuerza

Los servos pueden proporcionar 19,5kg.cm a 7,4v. Usamos 6v y la corriente en estado quieto resultó inferior a tres amperios.

   

Programación

Puedes obtener el código Arduino en el repositorio de Github del proyecto.

Se utilizan dos programas para la captura y reproducción de movimiento, una técnica similar a la que se usa en las películas. Empiezas poniendo al robot en una pose. Como los servos están predeterminados para apagar el motor, se pueden girar los servos a mano. Una vez que se tiene el robot en la posición deseada, se usa el programa Walbi_record para leer y mostrar todos los ángulos de servo. Usted luego alimenta esas lecturas de ángulo en la variable poseAngles en Walbi_play, y usa el programa para reproducir la secuencia de poses grabadas a una velocidad establecida por la variable timeToMove (en milisegundos).



Aquí hay algunos consejos y trucos aprendidos al crear Walbi:

  • Los soportes para el LX-16A solo se acoplan al servo en UNA posición, por lo que es muy fácil conectarlos incorrectamente, especialmente a las partes impresas en 3D. Tuvimos que reensamblar a Walbi un par de veces para corregir errores de montaje que eran bastante difíciles de detectar.
  • Los servos vienen con identificación ID 1 por defecto. Asigne a cada servo una ID diferente antes de montarlos en el robot, o será imposible comunicarse con varios servos serie conectados con la misma ID.
  • El uso de bridas para cables realmente mejora la apariencia.

  • Los servos vienen con los tornillos necesarios para conectar el disco de acoplamiento de los servos, y el disco a los soportes. Los soportes vienen con los tornillos necesarios para sujetarlos a los servos. Tendrá que comprar tornillos por separado para sostener las conexiones y para el soporte de las piezas de plástico. Se utilizan tornillos y tuercas DIN912 M2-6 y M2-10.
  • Es posible mejorar la tracción pegando almohadillas de silicona en las plantas de los pies del robot.

  • Es preferible usar discos de acoplamiento de metal para servo, ya que las de plástico que vienen provistas con los servos se romperán en el caso de que las piernas se golpeen durante las pruebas. Si estas piezas se rompen, el robot se aflojará y la reproducción del movimiento perderá precisión. De otra manera, es esta reproducción es sorprendentemente buena.

Piezas a medida

STL para piezas impresas en 3D (Originalmente impreso en un Flash Forge Creator Pro.)

Código Programas Arduino para control de movimiento y reproducción

En Alienexpress encontré algunas publicaciones que pueden servir de guía para obtener los elementos:

SERVO
JUEGO DE SERVO Y ACCESORIOS
SERVO Y PIEZAS DE MONTAJE