Hola, hace algun tiempo utilice los TLE 5206-2 de infineon son drivers muy potentes hasta 5A...

Con ellos, hice un pequeño controlador PWM con un 16F877 (TQFP), con el maneje los dos motores de un TER-1 para hacer un siguelineas programable...

Tienes mas info aqui http://www.jvmbots.com/viewtopic.php?t=183

Espero que te sea de ayuda....

Saludos

Quiza deberia empezar diciendo para que estoy montando este pifostio... bien: el unico robot con el que he tenido contacto ha sido el RCX de Lego, simple y sencillo de montar y programar, y ya que estoy "obligado" a hacer un robot con la Fonera, he decidido hacer una version del RCX ( http://graphics.stanford.edu/~kekoa/rcx/ ) de bajo coste y con esteroides, evitando todas las limitaciones que tenia este (empezando porque solo tenia 3 entradas de sensores y tres salidas de actuadores-motores) y haciendolo ampliable (de ahi el bus i2c y los dolores de cabeza que me esta dando).

El RCX original usaba solo dos hilos para cada sensor y cada actuador, y luego dentro del programa se definia de que tipo era cada uno, con lo que se tenia una gran libertad para trabajar ya que daba igual lo que pincharas: era una entrada analogica y dependiendo del tipo que le indicases interpretaba los valores de una forma u otra (lo mas divertido, usar el modo RAW para sacar los datos sin precisar y hacer un multiplexado de la leche metiendo sensores de todo tipo por una unica toma ). Esta parte mas o menos la tengo terminada usando un ADS7828 (un ADC de 8 canales de 12 bits) ya que me falta la circuiteria de apoyo (basicamente, llevar alimentacion a los sensores).

Respecto a los motores es donde tengo el problema, porque en principio deberia funcionar al reves que los sensores (si este era un ADC, aqui tocaria un DAC), peeeeeeeeeeeeeero me encuentro con el problema del cambio de sentido, que no se como abordarlo y mucho menos para que ocupe poco. Habia llegado a pensar en un puente H conectado a un port expander y hacer PWM por software, pero saturaria mucho el bus. Por eso decia lo de que si habia algun chip como el L293B para hacer el puente H pero con entrada de alimentacion para cada mitad por separado, para asi usar cuatro salidas por motor: 1 para activa/desactivar(giro libre), 2 para el cambio de sentido y bloqueo de las ruedas y el restante para hacer el PWM. En este sentido el PCA9531 (control de leds 8x8bits PWM) me viene al pelo, ya que cada toma es independiente, tiene reloj interno y ademas los puertos que no se usen esta preparado para usarlo como GPIO, ideal para controlar los motores. Si, lo ideal seria poder utilizar una unica salida (de ahi que si hubiese un DAC con posibilidad de elegir la polaridad me vendria de perlas, asi tendria 8 salidas independientes), pero mientras lo encuentro, esto es lo que gana por goleada.

Como se puede ver, de electronica yo poco, y por eso he pensado como informatico que soy y tengo pensado hacerme unas librerias en C++ para todo esto, de ahi el hecho de que parezca que haya dicho "incongruecias" como conectar un DAC a un puente en H que necesita entradas digitales y no analogicas: versatilidad. ¿Que es una señal digital mas que una señal analogica que cambia entre dos unicos valores constantes? 😉 Al tener salida analogica, solo tengo que decir "esta salida es de este tipo", y el programa ya se encarga del resto. Al fin y al cabo, la filosofia de la Programacion Orientada a Objetos le viene que ni pintado... "te he conectado al sensor 3 (clsSensor arraySensores_[]) un sensor de luz (arraySensores_[2].type=LUZ) y el valor negro esta a partir del 60% (arraySensores_[2].frontier=60)", y con los motores lo mismo. Mas claro, water

Os adjunto un esquema (SIN TERMINAR y SIN PULIMENTAR) para que veais por donde van los tiros de lo que yo quiero. Las lineas punteadas en SCL_IN es porque espero poder quitarlas ya que solo hay 3 GPIOs disponibles por el momento en la fonera y el SCL_IN no lo necesito (al menos para el uso que le voy a dar, no se el driver que tal...)

A la hora de diseñar un robot cuando solo se van a realizar una pocas unidades pues yo creo que lo principal es dividir. Es decir realizar módulos independientes con una función, y que el robot sea un conjunto de esos módulos, todo esto a nuestro nivel de aficionados.

Si buscas la filosifía de la programación orientada a objetos pues has de pensar en lo reutilizable, y controlar unos motores desde un DAC puede que de mucha libertad a tu robot a la hora de los periféricos que se le pueden conectar a una misma entrada y la facilidad de uso, pero ese módulo queda limitado a ese robot ya que es muy poco común controlarlo desde un conversor, por lo que pensandolo bien obtienes todo lo contrario de lo buscado inicialmente, según como se mire.

Si además vas a realizar el trabajo de crear librerias, pues lo suyo podía ser usar esas librerias en otros diseños, y que para añadir un módulo y desempeñe una función sea tan fácil como instanciar un objeto, ese módulo hard es el que ha de ser versátil, el soft siempre lo puedes cambiar/adaptar, el hard una vez hecho así se queda.

Todo es como lo quieras enfocar, si quieres que cuando muera el robot muera el resto, pues sigue el camino que llevas. Pero si mañana estas haciendo otro robot, puede que te baste con pinchar la tarjeta y usar la librería de esta y no tener que realizar otra para controlar los motores.

Yo haría modulos independientes lo más versátiles posibles, y me iría a lo que normalmente se usa, en el caso de la tarjeta para controlar los motores, pues como ya se ha dicho, le metería su propio pic con su entrada i2c, y el puente en H buscaría el que me permita controlar motores de mayor intensidad, ya que ahora quieres controlar dos motores, pero mañana quizás quieras controlar 4 motores poniendo dos en paralelo por canal, y entonces puede que el l293 se te quede corto. Tb pensaría en las entradas de los enconders ya que es una aplicación muy común y muchas veces necesaría. Y además de todo esto dejar entradas libres del pic, así si quieres podrías hasta pincharlo al dac de este diseño, hay pics pensados para controlar motores. Y por otro lado ya has pensado en añadir el bus i2c.

Otra ventaja de crear módulos independientes es que es más fácil encontrar el error cuando algo falla. Yo seguiría este camino, aunque puede que sea más difícil diseñar y dimensionar en un principio, a la larga seguro que es beneficioso, además de dar la posibilidad a otras personas de utilizarlos en diseños totalmente distintos.

Pero bueno esto sólo es mi opinión, que hablen los expertos en robótica =P

A la hora de diseñar un robot cuando solo se van a realizar una pocas unidades pues yo creo que lo principal es dividir. Es decir realizar módulos independientes con una función, y que el robot sea un conjunto de esos módulos, todo esto a nuestro nivel de aficionados.

Hombre, parece que es un unico circuito pero no era mi intencion... Si te fijas cada una de las partes es un modulo independiente que se conectan todos en comun al bus i2c.
Si buscas la filosifía de la programación orientada a objetos pues has de pensar en lo reutilizable, y controlar unos motores desde un DAC puede que de mucha libertad a tu robot a la hora de los periféricos que se le pueden conectar a una misma entrada y la facilidad de uso, pero ese módulo queda limitado a ese robot ya que es muy poco común controlarlo desde un conversor, por lo que pensandolo bien obtienes todo lo contrario de lo buscado inicialmente, según como se mire.

Interesante... Si, tienes razon, lo limitaria a este robot... si la libreria esta mal diseñada. La ventaja de la POO es que puedes cambiar unos modulos por otros, y si en lugar de usar un objeto de clase clsInterfazActuadorI2cDAC usar un objeto de clase clsInterfazActuadorGPIO, el resto de la libreria y por tanto de los componentes se mantendrian. Habria que programar dicha interfaz y modificar el programa, es logico, pero tampoco tanto como crees... (los nombres de las clases son inventados, todavia no he programado nada y de hecho ni he podido flashear la fonera, pero son bastante explicativos...)
Si además vas a realizar el trabajo de crear librerias, pues lo suyo podía ser usar esas librerias en otros diseños, y que para añadir un módulo y desempeñe una función sea tan fácil como instanciar un objeto, ese módulo hard es el que ha de ser versátil, el soft siempre lo puedes cambiar/adaptar, el hard una vez hecho así se queda.

¡Por eso! Los modulos seran "estandar", los que han de ser versatiles son los interfaces, o sea, el DAC y el ADC o lo que termine usando. Ademas, siempre se pueden diseñar nuevos interfaces y tampoco seria tan caro (espero que no me sean caros los chips... :-/ )
Todo es como lo quieras enfocar, si quieres que cuando muera el robot muera el resto, pues sigue el camino que llevas. Pero si mañana estas haciendo otro robot, puede que te baste con pinchar la tarjeta y usar la librería de esta y no tener que realizar otra para controlar los motores.

Pues justamente por la poca experiencia que tengo me parece que este es el camino a seguir si quiero que sea lo mas reutilizable posible en el futuro... un bus estandar como es el i2c, unas interfaces analogicas programables y una libreria para hacer que actuen como lo que son (analogicas) para conexion directa o que emulen un comportamiento digital para conexion de otros modulos mas "elaborados"... Creo que la clave esta justamente en hacer que el sistema dependa lo mas posible del software, que es siempre la parte mas flexible... Siempre se puede modificar o ampliar en el futuro...
Yo haría modulos independientes lo más versátiles posibles, y me iría a lo que normalmente se usa, en el caso de la tarjeta para controlar los motores, pues como ya se ha dicho, le metería su propio pic con su entrada i2c, y el puente en H buscaría el que me permita controlar motores de mayor intensidad, ya que ahora quieres controlar dos motores, pero mañana quizás quieras controlar 4 motores poniendo dos en paralelo por canal, y entonces puede que el l293 se te quede corto. Tb pensaría en las entradas de los enconders ya que es una aplicación muy común y muchas veces necesaría. Y además de todo esto dejar entradas libres del pic, así si quieres podrías hasta pincharlo al dac de este diseño, hay pics pensados para controlar motores. Y por otro lado ya has pensado en añadir el bus i2c.

Interesantes tus argumentos, pero creo que los dejare para una edicion posterior (no tengo tiempo ni ganas como para aprender a programar un PIC), pero precisamente esto demuestra la potencia de mi planteamiento: solo habria que añadir a la libreria la clase clsActuadorPIC y listo. Eso si, lo de implementar en la misma tarjeta el hardware necesario para poder usar los encoders de un motor en concreto me ha convencido para usar el PIC (por ejemplo, permitiria que se autocentrara en una posicion sin requerir de la CPU principal), pero repito, para mas adelante 😉
Otra ventaja de crear módulos independientes es que es más fácil encontrar el error cuando algo falla. Yo seguiría este camino, aunque puede que sea más difícil diseñar y dimensionar en un principio, a la larga seguro que es beneficioso, además de dar la posibilidad a otras personas de utilizarlos en diseños totalmente distintos.

Precisamente se me ocurrio este diseño al querer poner en practica lo de "piensa en grande, actua en pequeño", porque al principio pensaba usar los (pocos) GPIOs de la fonera directamente multiplexandolos. Ademas, ¿te parece poco reutilizable por otras personas el tener el interfaz i2c como centro de todo? 😀
Pero bueno esto sólo es mi opinión, que hablen los expertos en robótica =P

No, no, se agradece tu opinion... 😉

Ea, ahora los expertos 😀

Ningún interfaz es más versátil que el hecho con un pic, pero si no es opción que se le va a hacer.

Otra ventaja del pic es que una vez conectado el mismo puede decir que tipo de objeto es, y establecer sus parametros, cosa que no tendrías que hacer a mano. La verdad que un proyecto así sería bonito construyendo un robot de iniciación como el que se emepzo aquí con todo su hard y soft.

El PC8574 es un expansor de bus I2C que funciona como entrada y salida latcheada, aunque si el PCA9531 que nombras, si te deja poner su duty a 0 y 100 puede que no te merezca la pena. Ventaja sobra el adc y el pca es que es bidireccional, si es que estos puedes usarlos así.

El l298 te permite controlar dos motores en dirección y velocidad independientemente, con seis señales creo recordar, y creo que el 293 tb, no sé echale un ojo a los datasheet.

Cualquier aparato electrónico lleva n micros así que más tarde o más temprano te tendrás que ver con ellos.