Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Quiero hacer pruebas mecánicas con diferentes tipos de estructuras de servos con el fin de practicar. Para lo cual he adquirido la controladora SD21. Y hasta que tenga mayores conocimientos la usaré conectada directamente al PC mediante este adaptador USB a I2C
Debido a mis insuficientes conocimientos de electrónica tengo dudas sobre el tipo de alimentación que deberé realizar y no quiero hacer ninguna prueba de momento porque no quiero meter la gamba y cargarme algo.
Disponemos de dor formas de alimentar al Driver para servos SD21. La primera consiste en emplear una tensión de +5Vcc para alimentar a toda la lógica de control y otras tensión de entre 6 – 7,2V para la alimentación de los servos. A tal efecto se dispone de una regleta con 4 bornas o clemas. Las señales de GND para la lógica y para los servos son comunes.
Otra forma típica de alimentación es mediante el empleo de un packs de baterías que suministran una única tensión de 7.2V. En este caso se cierra el jumper puesto al efecto y la tensión de +5Vcc se obtiene a partir de esos 7,2V gracias al regulador que incorpora el propio módulo SD21.
Tengo pensado usar alimentación independiente. Por un lado con un adaptador AC/DC con salida a 6V para los servos. Y para el circuito como funciona a 5V desearía poder usar los que proporciona el Conversor USB (70mA).
The +5v supply from the USB-I2C module can supply up to 70mA to external devices. If your I2C device requires more than this, or has its own supply, then leave the +5v pin unconnected. Do not apply your own 5v supply to this pin.
¿Usar el adaptador a 7,5V para una alimentación común en lugar la batería sería posible?
Especificaciones técnicas USB-I2C
Especificaciones técnicas Controladora Servos SD21
A ver si me podéis echar un cable, ¿Qué pensáis que debería hacer?. Mi intención es evitar el uso de baterias, pero si tengo que usar el adaptador para los servos y pilas para el circuito casi me vendría mejor comprar una bateria de 7,2V para alimentar todo.
16 lecturas, 0 respuestas, vaya éxito 🙂
No pude resistir la tentación y le metí 6v desde un adaptador con el método de alimentación única, y le conecté un servo. En principio parece que funciona bien. Digo en principio porque no consigo que reciba los comandos de cambio de posición.
Al conectar la corriente automaticamente el servo es llevado a la posición central, y al intentar girar el disco con la mano se nota la fuerza que hace para retenerlo en la posición, por lo que parece que funciona correctamente.
El conversor USB-I2C parece funcionar también correctamente; lo abro como si fuera un puerto com, obtengo el número de versión, apago/enciendo el led rojo, y al enviar los datos el led verde parpadea.
Conecto el conversor al controlador mediante sus conexiones SCL,SDA y GND.
El problema es que al enviar un cambio de posición el servo permanece en su posición central sin hacer absolutamente nada. En cambio si lo hago con el controlador sin corriente a veces en el momento de conectarlo es llevado a la nueva posición que establecí anteriormente.
Aquí está parte de la información para comunicarse con el controlador I2C
3.- CONTROL DEL SD21
Se accede a él mediante el protocolo I2C con la dirección 0xC2. Dispone de tres registros internos por cada uno de los 21 servos que puede gobernar. Un registro determina la velocidad y los otros dos la anchura del pulso
expresada directamente en µS. Ver la siguiente tabla.
Registro Servo Nº Función
.....0...........1.........Velocidad
.....1...........1.........Pos. Byte L
.....2...........1.........Pos. Byte H
Este es el procedimiento para enviar un comando a un dispositivo con registros internos desde el conversor USB-I2C.
5.3 Escribiendo un dispositivo I2C con registros internos
Es una de las operaciones clásicas a realizar con cualquier dispositivo I2C. Tras el comando primario I2C_CMD (0x55) se manda la dirección del dispositivo en modo escritura, la dirección del registro interno sobre el que se quiere escribir, el número de bytes a escribir a partir de esa dirección interna y los bytes a escribir propiamente dichos.
Este es el mensaje usado, intento poner el servo en la posición 1200 (0x04B0)
BYTE buffer[8] =
{
I2C_CMD,// Mensaje I2C
0xC2, // Direccion Controlador de servos
0x01, // Registro de posicion del servo 1, byte bajo
1, // Enviar un byte
0xB0, // Byte de posicion bajo
0x02, // Registro de posicion del servo 1, byte alto
1, // Enviar un byte
0x04, // Byte de posicion alto
};
WriteCom(buffer, 8);
¿Qué estoy haciendo mal?, ¿la Alimentación?, ¿la conexión?, ¿El mensaje?. Se aceptan sugerencias.
.... Conecto el conversor al controlador mediante sus conexiones SCL,SDA y GND.
El problema es que al enviar un cambio de posición el servo permanece en su posición central sin hacer absolutamente nada. En cambio si lo hago con el controlador sin corriente a veces en el momento de conectarlo es llevado a la nueva posición que establecí anteriormente.
El hecho de enviar un comando, que no se ejecute pero enviarlo con el dispositivo apagado y que se ejecute al encender.... a mi me suena a información almacenada en el buffer que no es leida por el dispositivo o lo que es lo mismo, un problema en el protocolo de comunicación.
la posición deseada se queda en el buffer del conversor USB->I2C, no tengo ni idea de que componentes usa este conversor, pero por experiencia con componentes de ftdichip te digo que los datos USB van hasta el buffer del CI (ftdichip) y hasta que no se le da la señal de lectura la información quedará atascada en el buffer de forma permanente, pero si se resetea el otro dispositivo el cambio de 1 a 0 o viceversa de la patilla de lectura hace que en ese momento se ejecute correctamente.
furri.
Sí, El chip es FTDI FT232BM.
Pero en la documentación no veo que tenga un orden para dar la señal de lectura. Y no hay byte de fin de mensaje, se supone que ejecuta los comandos inmediatamente, por eso se define el número de bytes de datos.
¿qué puedo hacer? 😕
(Todo esto no es mas que pura especulación)
Hace tiempo con un programa en C++ sobre linux creo recordar que algunos comandos enviados por el Com1: no se ejecutaban hasta que no cerraba el puerto lo que me obligaba al proceso:
- Abrir puerto.
- Enviar comando.
- Cerrar puerto.
Al final pude dejar de hacerlo con algo que modifiqué en la configuración del propio puerto Com1.... pero eso lo hice hace como 5 o 6 años y desde entonces solo he usado el puerto ComX con Visual Basic... creo que Mif publicó un proyecto sobre puerto serie en alguna sección de ARDE, echale un vistazo.
furri.
