AnalogHub i2c

Saludos,

“That is not dead which can eternal lie, And with strange aeons even death may die”.

No hoy no vengo a haceros entrega de una nueva aventura de la llamada de Cthulhu, aunque estaría bien. Hoy trato de arrancar nuevamente el foro tras un periodo de silencio, mucho trabajo principalmente.

Hoy vengo a presentaros un “AnalogHub I2C” basado en el PIC16f1503, no es nada nuevo ya hice algo similar con la entrada de la Pi Zero. Pero en esta ocasión es una plaquita más ligera y que se puede añadir a cualquier proyecto uses, Arduino, raspberry pi, teensy, Intel edison , etc.

Imagen de una placa sin soldar y otra hecha.

   

Las placas las he pedido a Seeedstudio, realizan un trabajo muy fino a un precio muy competitivo. Entre otras cosas funcionan tan bien como OshPark, simplemente les subes el pcb a su pagina y te realizan un presupuesto.

Que tienen estas placas:

·         Puerto i2c

·         Un led controlable.

·         5 entradas Analógicas

·         2 controladores de servo

Evidentemente la funcionalidad de los puertos se puede modificar si modificas el programa del pic. Como funciona, la placa puede dar el valor de la analógica que se le pida, en una resolución de 16 bits, de forma automática se obtiene 5 muestras y se da la media.

·        

•  Modo lectura Master escribe al AnalogHub un byte :

o   0x30 à El master ha de leer 2 bytes de la entrada Analogica 0

o   0x31 à El master ha de leer 2 bytes de la entrada Analogica 1

o   0x32 à El master ha de leer 2 bytes de la entrada Analogica 2

o   0x33 à El master ha de leer 2 bytes de la entrada Analogica 3

o   0x34 à El master ha de leer 2 bytes de la entrada Analogica 4

o   0x35 à El master ha de leer 2 bytes de la entrada Analogica 5

o   0x36 à registro de control, el master lee 2 bytes que son ‘1234’

  Ejemplo de Arduino

Wire.beginTransmission(address);  // Address of AnalogHub   Wire.write(op); // option   dato=i2cReadbyte(address);   dato|=i2cReadbyte(address)<<8;   Wire.endTransmission();   delay(15);

En modo control he implementado un control de servos en continua, que nos permitía realizar un simple robot con ruedas, una vez enviada la instrucción los motores ruedan un tiempo determinado y se paran hasta recibir su siguiente instrucción, de normal son 100 ms. 

·          

• Modo control del Master al AnalogHub:

o   Master escribe un byte

§  0x01 à El led se enciende

§  0x02 à El led se apaga

o   Master escribe 2 bytes

§  Modo robot con  servomotores en continua

·         0x20 + [0..50]à forward

·         0x21 + [0..50]à backward

·         0x22 + [0..50]à turn right

·         0x23 + [0..50]à turn left

·         0x24 à stop

§  Modo Servos

·         0x26 + [0..180] à control servo 1

·         0x27 + [0..180] à control servo 2

o   Master escribe 3 bytes

§  0x25 + [0..255] + [0..255] à Parte baja y parte alta del delay entre motores en modo robot, de normal está en 100 ms

§  0x69 + [0..255] +[0..255] à Parte baja y parte alta de la media de muestreo para las lecturas analógicas. De normal está en 5.

Ejemplo Arduino

Wire.beginTransmission(address); // Address of AnalogHub  Wire.write(op); //opcion  Wire.write(data);// data is uint16_t  Wire.write(data>>8);  Wire.endTransmission();

Lo único que hay que considerar es los tiempos entre las instrucciones de control, si le enviamos dos órdenes sin dejar el tiempo suficiente para que se completen la segunda orden posiblemente no llegue. Si el tiempo medio de instrucción de control de los motores es 100ms el tiempo mínimo ha de ser 100ms entre instrucción. Ajustando mucho.

Conexiones

La alimentación puede ser a 3,3 o 5V, en función de los sensores que necesitéis conectar. Para la alimentación de los servos/motores se recomienda una alimentación a parte de la tensión de control, las pruebas realizadas con servomotores de dfrobot  no fue necesaria alimentación extra, pero tampoco tenía puesto ningún sensor.

Conclusión

El AnalogHub esta pensado para deslocalizar funciones básicas como leer sensores y controlar motores, bien porque el master no posea estas funciones o para reducir el nivel de código en este sentido. No deja de ser un prototipo y se hecha en falta un segundo puerto I2c para poder conectar varios en cascada e la inclusión de un puerto extra para la alimentación de los motores. Pero abre la puerta a desarrollar robots modulares, que sean plug and play para el master.

Anakleto

CAN bus + Teensy

Saludos,

bueno hace mucho que no público, y bla bla bla bla. No os voy a contar mi vida... Hoy vengo a hablaros de un proyecto en el que estoy trabajando control de la iluminación de un suelo interactivo. El suelo en si ya existía, pero la iluminación de cada baldosa estaba hecha con 3 lámparas de Neon, un RGB sencillo pero muy caro en consumo eléctrico.  La nueva versión esta pensada hacerse con Leds.

Exactamente los test y pruebas las estamos haciendo con WS2811, hubiera preferido usar Neopixels, pero una confusión me hizo pedir estos, la diferencia más gorda es que el neopixel lo controlas led a led, y con la tira de WS2811 va de tres en tres, los rimeros funcionan a 3V y los segundos necesitan 12v.

Para el control de los leds me base en este proyecto desarrollado con la placa teensy 3.2, la librería OctoWs2811 no funciona en Arduino, pero podéis controlar los leds con la misma librería de Adafruit Neopixel. Empleando un teensy y colocándoles un resistencia a la salida de 100 ohms  la salida del teensy me daba para controlar 48 puntos de luz, 144 leds. Para conseguir encender mas leds seria necesario colocar un bufer  a 5v. Los dos intentos que ha he hecho a este respecto han fracaso.

VPWM0 son 5V y el transistor que regula la conmutación BC547	Driver 74LS07D

El primer montaje funciona y la salida es igual que la entrada, pero a 5V con la corriente que proporciona el LM7805, pero dee introducir un cierto retraso que hace que los leds WS2811 no se enteren de la señal que reciben. El segundo montaje debería ser con el 74HTC245, pero en su lugar encontré el 74LS07D que yo pensé que era equivalente, hay que leerse bien los datasheets, porque el comportamiento que tiene es totalmente diferente, sin entrar en detalle los leds no responden, por lo tanto, no funciona.

Llegado a este punto pensé 48 puntos de luz por salida no está nada mal…

Disposición aproximada de las baldosas

Cada baldosa mide 76cm de diámetro y 15,5 cm de alto, llevan un difusor y un cristal de unos 4 cm de grosor, cada baldosa incluye 3 sensores de presión, en total hemos colocado 120. El suelo forma parte de una sala interactiva que tendrá 4 pantallas donde se proyectaran, convirtiéndola en una especie de holocubierta, para hacer experimentos de realidad mixta, VR … Y si puedo hacer una adaptación del Heroquest.

Test con una tira de 48 puntos de luz

Empleando el StadarTest de Neopixel probamos como se vería una de las baldosas y como se hacia la transición, este test está hecho con los leds pegados a la base de la baldosa y empelando una fuente de 3A de corriente a 12 V.  Con una fuente de estas características se pueden alimentar a 96 puntos de luz 288 leds sin problema, con tres baldosas 432 la ultima baldosa fallaba cuando se le envía el color blanco, los tres RGB encendidos.

Pero para la instalación final queríamos un patrón uniforme para “poder hacer algunas animaciones” en las baldosas, las comillas es debido al difusor las animaciones deberían ser muy simples. Hemos optado por hacer un patron  que nos permita colocar los leds de forma uniforme.

Diseño en Sketchup y disposisón de los WS2811

En realidad este post no venía a comentar el proyecto entero, simplemente para controlar las 120 baldosas teníamos que escoger un método de control que nos permitiera control, velocidad de respuesta y protegido a interferencias, y actualizable, este ultimo punto en principio era importante, no me quería ver levantado baldosa por baldosa para instalar la nueva versión de la librería o corregir un error. Baraje la opción de emplear una raspberry pi 3, la librería de neopixel esta desarrollada en Python pero solo me limitaba a usar los pines PWM0 y PWM1. El tiempo de respuesta a  hacer funcionar la librería era alto, unos 5 segundos hasta que comenzaba a funcionar el standtest, la conexión seria mediante cables ethernet, el numero de baldosas que controlaría cada placa seria 2 y en el mejor de los casos 4 usando las dos salidas simultáneamente, si era posible hacerlo. Los sensores de presión irían conectado a una placa que enviaría la información a la raspberry pi mediante I2C.

Con los teensy el control era muy rápido y robusto, había realizado mas pruebas y con la librería OctoWS2811 podría conectar 16 baldosas por teensy, 8 lineas de 38 leds + 16 placas de i2c con la información de los sensores de presión…. Pero como se comunicarían entre ellas, RS232, RS485, I2C, Ethernet… Finalmente opte por Can Bus, es un protocolo normalizado, con inmunidad a interferencias y protocolo para detectar y corregir errores. Además el teensy tiene de serie un puerto para el bus can, lo que lo hacia el candidato excelente para testear.

Siguiendo esta guía, y empleando la librería flexcan, me hice con mis plaquitas  SN65HVD230 o similar por amazon, diseñe la paca en Eagle para integrar todo lo necesario y me lleve un fiasco cuando era imposible enviar nada, no funcionaban. O no he sido capaz de hacerlo funcionar. La otra placa que compre a la desesperada fue la MCP2515, especial para Arduino y que, al conectarla a un teensy, desaprovecharía su bus can, en realidad solo necesitaría el MCP2551, y es posible que lo compre en un futuro y o integre a la placa final.

SN65HVD230	MCP2515

Diferencias entre las placas muchas, las primeras son un simple conversor de niveles eléctricos al protocolo del bus, pero todas las pacas vienen con la resistencia de 120 Ohms conectada, Este protocolo debe tener una resistencia al principio y al final, pero si quieres conectar tres de estas plaquitas, debes quitar la resistencia en la placa del medio. La segunda, placa gestión el bus can, con un conversor de niveles el MCP2510 el U1, esta placa incluye un jumper que te permite colocar la resistencia o no. Por otro lado requiere de unos cuantos cables mas que las primeras.

Teensy 3.2	MCP2515
Pin digital	Int
13	SCK
11	SI
12	SO
10	CS
GND	GND
VIN	VCC

Para emplear esta placa utilice la librería MCP2515 de Arduino y conseguí que entre los dos teensy se enviaran mensajes el siguiente paso era comprobar que podría controlar los 2280 puntos de luz del suelo de forma fluida, no es que deba cambiarse con mucha frecuencia pero si es necesario, que la transición no tenga demasiado delay.


Editado: La librería ha sido modificada si tenéis problemas con la nueva, podéis usar MCP_CAN_lib-master.zip  

                                                                                                                                                                       

A continuación, os dejo unos vídeos de unas pruebas que hecho, ahora toca depurar código para gestionar mejor los paquetes de información, numero de mensajes, etc. Y hacer unos nuevos prototipos para probar “in situ”.

Test de la baldosa con 19 leds en disposición.

Test de control secuencia RGB a 1000Kbaudios y a 500Kbaudios

En estos dos últimos test el teensy de control esta enviando los 2280 mensajes, que supuestamente leerán los teensy distriubuidos, como solo disponía de una tira de leds de 7 leds la secuencia con la que envió el mensaje es primero enciendo el primer punto de luz de todas las baldosas, después el segundo y así hasta 19. La forma que tienen de encenderse los leds es representativo de como se encendería todo el suelo.

Anakleto.