Robot Hexapodo

[gera]

Pajaro, qué tal?
Mira, el proyecto esta un poco parado porque la semana que viene estoy presentando mi trabajo de fin de carrera.
Sin embargo, ya pedi los componentes y estan en camino
Compre 20 servos, una bateria lipo, unos reguladores LM2678 y unos PIC18F4550 en formato TQFP.
Ademas un amigo se quiso sumar al proyecto y me va a dar una mano con la construccion y programacion. Por lo pronto tenemos que diseñar el circuito para poder controlar los 18 servos con el PIC.
Cuando lleguen las cosas y tenga algo armado lo comparto con uds!
Saludos y gracias por el interes!

[willynovi]

Gera, a mi tambien me interesa este proyecto, por ahora estoy armando un simple programita en Visual C para controlar unos servos manualmente via HID.
En el PIC no tengo mucho desarrollado, la idea es hacer algo similar a los link que mas arriba te pasé.

Ya tenes alguna idea de como controlar los servos, digo mejor, resolución, cantidad de servos (supongo mínimo 18).

Si fuera necesario, te puedo dar una mano en algo y aunamos esfuerzos 

[gera]

Hola Willy!!
Mi idea es hacer una aplicación para la PC en Processing y utilizar una comunicación USB-CDC porque es con lo que estoy más familiarizado. Está buena la idea de hacerlo HID, pero no tengo mucha experiencia con este perfil, sobretodo del lado de la PC. Me podrías contar un poco sobre eso?

En principio la aplicación facilitaría controlar los servos individualmente, grabar posiciones y movimientos predefinidos por el usuario. Luego iría por el tema de cinética inversa.
La placa la voy a diseñar para que permita conectar 20 servos (18 para las patas, dos por si el día de mañana le pongo una cabeza o algo). Seguro le voy a dar acceso a la UART del pic para debugging, ISCP, USB y algún LED de estado.
Qué opinas? Se me olvida algo?

Saludos!

[willynovi]

Supongo que cada uno se siente cómodo con lo que ya ha aprendido.

Experimenté tanto con la API especifica de Microchip, con el CDC y por último con el HID porque tuve la necesidad de hacer un dispositivo de juegos que tenia salidas desde un simulador.

Si mal no recuerdo la parte de comunicación es similar y hoy no se decirte que ventajas hay sobre uno u otro, en su momento abandoné la API de Microchip porque no tenia compatibilidad con W7, aunque hoy quizás si la tenga.

Tanto el CDC como el HID creo que son aptos para la aplicación, aunque siempre teniendo en cuenta, y para empezar, que dependes del cordón umbilical.
De todos formas los programas para uno u otro modo de comunicación tienen que ser compatibles, obvio quitando la parte especifica de comunicación.

Cuando intentes hacer una comunicación inalambrica pensaras en bluetooth o similar.

Yo voy por HID porque mi idea es montar una netbook sobre el robot y luego comunicarme con otra PC por wi fi.

A medida que valla encontrando tiempo y avance con el tema de los servos voy colgando los avances.

Con respecto a lo de Processing no tengo mucha idea, igual creo que sigo con C para no perder lo avanzado.

[gera]

Cuando intentes hacer una comunicación inalambrica pensaras en bluetooth o similar.

Yo voy por HID porque mi idea es montar una netbook sobre el robot y luego comunicarme con otra PC por wi fi.

A medida que valla encontrando tiempo y avance con el tema de los servos voy colgando los avances.

Con respecto a lo de Processing no tengo mucha idea, igual creo que sigo con C para no perder lo avanzado.

Exacto, pienso utilizar un modulo bluetooth. Estos modulos funcionan como un puente serial, por lo tanto una vez definida la trama, puedo utilizar el puerto serie del pic, el USB o el modulo bluetooth indistintamente. Por eso digo de usar USB-CDC.
Mi robot es muy pequeño como para montarle una notebook encima. Sin embargo tengo la duda de por que le montarías una notebook 

Bueno, de paso les comento que una primera version del circuito. Utilizo un regulador switching LM2678 para la alimentacion. Entrega hasta 5A, asique creo que voy a estar sobrado.
El modulo central tiene un PIC18F4550, con todos los pines para conectar los servos, un conector ICSP, puerto USB, y aún me falta ver como voy a hacer con el modulo bluetooth, ya que tengo que hacer una adaptacion de tensiones de 5V a 3.3V.
Obviamente aún falta bastante, pero les muestro un adelanto de como esta quedando



Acepto críticas y sugerencias de cualquier tipo.
Gracias y saludos!!

[willynovi]

El tema de montar la netbook ensima es para en un futuro darle mas autonomia con algún reconocimiento de imagen o a sensores de distintos tipos.

Estuve investigando un poco el tema del control de los servos, si bien estoy en etapa de investigación y madurar conceptos, vi algunos ejemplos de hasta 33 servos y los comentarios son buenos, el tema es que usan instrucciones de direccionamiento indirecto y ahí medio que me perdí, así que me he puesto a ver como es que trabaja el programilla.

Les dejo unos links por si quieren darle un vistazo.
IMPOSSIBLE? 30 Servos with USART Comm on Single 40-pin PIC
Drive 33 Servos With One PIC + USART

[gera]

Ahh ok. Lei muy rapido los ejemplos que me enviaste, y si no me equivoco, es el mismo metodo para generar ondas de PWM que nos muestra Manolo aqui:
http://www.micropic.es/mpblog/2007/09/generacion-de-3-pwm-probamos-led-rgb/

Es justamente el metodo que pienso utilizar. Con una interrupcion de timer y un contador, primero pones todos los pines en alto, y a medida que el contador va alcanzando los valores de duty de cada servo, vas poniendo los pines en bajo. En el link que puse esta mucho mejor explicado.
Cuando tenga la placa lista, haremos unas pruebas a ver que tal funciona

Saludos!!

[Nocturno]

¡Muy bien exprimidos esos micros para sacar 30pwm!

[willynovi]

Ahh ok. Lei muy rapido los ejemplos que me enviaste, y si no me equivoco, es el mismo metodo para generar ondas de PWM que nos muestra Manolo aqui:
http://www.micropic.es/mpblog/2007/09/generacion-de-3-pwm-probamos-led-rgb/

No pude bajar el archivo con el proyecto, sería posible al menos disponer del código por aquí?

Lo que pude ver en los ejemplos que puse mas arriba, es que se atiende los servos primero en la interrupción y luego queda libre el micro para recibir los datos.

Bosquejando un poco sería,
La rutina de interrución dura 2,5mseg y luego sale para atender la recepción de datos durante los 17,5mseg restantes para completar el período de 20mseg.
Dentro de la rutina de interrupción se hace como decis vos, (según la frecuencia de trabajo del micro y el tiempo de instrucción se puede llegar a mayor resolución, aunque creo que contar con una resolución mayor a 100 puntos ya es mucho y los ejemplos son de 256).
Primero hace un delay de 0,5mseg y luego en un loop de 256 pasos (maxima resolucion) decrementa un contador por cada servo para que aproximadamente se cumpla el proceso en 2,5mseg.

No me resulta complicado el proceso, pero lo que alcancé a entender que con el direccionamiento indirecto se logra bajar la cantidad de instrucciones de la rutina de servicio de la interrupción, que puede ser critico si se trabajara con un uC con limitaciones en la frecuencia de trabajo, aunque no creo que sea un problema con nuestro 18f4550.

Lo otro que pensaba es que nuestro PIC de comando de servos tiene que ser medio "bobo", o sea, recibe datos y mueve servos, no creo que se le pueda pedir mucho mas.

[gera]

Yo creo que 256 es una resolución aceptable. 60º/256 nos da una resolución de 0.23º.

No me resulta complicado el proceso, pero lo que alcancé a entender que con el direccionamiento indirecto se logra bajar la cantidad de instrucciones de la rutina de servicio de la interrupción, que puede ser critico si se trabajara con un uC con limitaciones en la frecuencia de trabajo, aunque no creo que sea un problema con nuestro 18f4550.

Lo otro que pensaba es que nuestro PIC de comando de servos tiene que ser medio "bobo", o sea, recibe datos y mueve servos, no creo que se le pueda pedir mucho mas.

El 18F4550 es muy potente, y trabajando a 48MHz el control de los servos no va a ser problema. Además, como se trabaja por interrupción de timer, el procesador no va a quedar bloqueado. Habría que ver si hay conflictos con las interrupciones cuando llegan datos por el puerto serie (sea fisico o virtual). Supongo que puede resolverse estableciendo bien las prioridades.

En principio mi idea es enviar desde la PC una trama que contenga las posicion deseada de cada servo. Por ej:
"128,0,100,x,x,25,...\r\n"
Donde "x" significa sin cambios. También podría actualizarse la posición de cada servo por separado. Por ej:
"S01:128\r\n"
Donde "S01" sería un ID del servo, y luego la posición deseada.
Creo que el primer método es más conveniente, ya que los servos se van a actualizar simultáneamente y la trama es más corta en caso de actualizarlos a todos juntos. Aunque podrian implementarse ambos métodos a la vez.

Sin embargo, en el futuro pienso darle cierta autonomia al robot. Por lo tanto el micro seria el responsable de hacer los calculos de las posiciones de las patas y no la PC. Si en esa etapa me quedo corto con el micro, voy a dejar un micro dedicado a generar las señales PWM, y otro que realice los calculos y le envie las posiciones de los servos.

Qué opinan?
Saludos!!

[willynovi]

Cuando dices 48Mhz te refieres al oscilador interno cuando el externo es de 20Mhz?

De la forma que pienso la rutina de interrupción es bloqueando el main(), es decir, hasta que no termina la modulación del pulso de 2,5mseg (todos los servos a la vez) no vuelve al programa principal.
Por ahí se podría ver la forma de llevar esos 2,5mseg a solo 2mseg si el ancho del pulso inicial para indicar la posicion cero del servo la manejamos con una interrupción.

De esta forma podemos tener una buena resolución del movimiento de los servos, que está claro que 256 ya es suficiente 

Así tendríamos ocupado el micro máximo 12,5% con la atención de los servos.

Hago este análisis solo para compararlo con lo compartido por Guillermo haya por el 2008, que su programa se basa principalmente en interrupciones, pero está limitado en la resolución.

Si nos vamos por el lado que el PIC dedicado al control del servo sea "bobo" creo que con 17,5mseg tiene que alcanzar para transmitir nuestros datos, que si fueran 30 servos estariamos enviando 30 bytes.
Creo que es por donde tenemos que ir, y si fuera necesario alguna autonomia del robot dedicar otro micro "cerebro", siempre pensando que cualquier calculo matematico resulta pesado para nuestro PIC.

La forma mas eficiente de pasar los datos creo que es indicando directamente la posicion de cada servo uno a continuación del otro.
No entiendo mucho eso de poner una X, creo que trae problemas, en definitiva es un byte.
Tambien hay que recordar que cada 20mseg tenemos que refrezcar el valor de cada servo para realizar el decrementeo de cada uno en la rutina de manejo de servos. Con cargarle nuevamente el valor es suficiente.
Como decis vos Gera, enviar la trama completa es mas conveniente, aunque por alguna cuestion de pruebas se podria enviar un valor puntual a cada servo. Implementando el primer byte como un código y que a partir del segundo byte sea los valores de cada servo, y en otro caso el número de servo y la posición. Supongo que esto es un simple detalle 

Lo que yo opino es que estamos alineados, salvo por el tema de la comunicación 

Pregunta, aunque espero poder respondermela solo cuando haga los calculos 
Es posible saber cual es la cantidad máxima de bytes que se pueden enviar en 17,5mseg a un determinado baud rate?
La misma pregunta pero para una comunicación HID full speed?

[gera]

48MHz sería la frecuencia del oscilador interno (el pic ejecutaria a 12MIPS). Se obtiene a partir de 4MHz pasados por un PLL que los multiplica por 12. Y a su vez, esos 4MHz pueden provenir de un cristal de 12, 16 o 20MHz. En la hoja de datos del 18F4550 hay todo un apartado para la configuracion de los osciladores.

Creo que te estas enroscando demasiado los tiempos. O quizas yo estoy subestimando la complejidad del problema jeje. El procesador ni se va a enterar de las interrupciones. O sea, vamos a tener una interrupcion de timer que lo unico que va a hacer es incrementar un entero y compararlo con los distintos duty de cada señal PWM que tengamos.
El periodo de esa interrupcion depende del periodo de la señal de PWM, que en nuestro caso es de 20ms. En esos 20ms debemos interrumpir tantas veces como valores diferentes (resolucion) deseemos. Entonces 20ms/256=78.125us. Comparado con los 0.083us que demora un ciclo de ejecución, nos da una eternidad para realizar procesamiento entre una interrupcion y otra.

Con respecto a tu pregunta, si se puede calcular cuanto demora una trasmision de N bytes a una determinada velocidad. Sin embargo no creo que importe, ya que la idea es administrar la recepcion por interrupcion. O sea que cuando llegue la trama, se almacena en un buffer y luego se la puede procesar en el bucle principal.

[willynovi]

Si puede ser que me esté enroscando. Hasta que no haga algo de programa no debería hacer muchos cálculos mas 

Recuerda que si bien el periodo del PWM es de 20mseg, los 256 pasos no son en esos 20mseg, sino que en los primeros 2,5mseg.

Lo del tiempo de instrucción y los calculos del timer voy a tener que repasar la hoja de datos como decis, son cosas que se me olvidan muy facil 

Mi configuracion es así

Código: [Seleccionar]

        #pragma config PLLDIV   = 5         // (20MHz crystal)
        #pragma config CPUDIV   = OSC1_PLL2   
        #pragma config USBDIV   = 2         // Clock source from 96MHz PLL/2
        #pragma config FOSC     = HSPLL_HSLuego calculo bien el TCY, aunque si alguien lo calculara o me diera una ayudita no me ofendo 

[gera]

Recuerda que si bien el periodo del PWM es de 20mseg, los 256 pasos no son en esos 20mseg, sino que en los primeros 2,5mseg.
[\quote]

Tenes razon! Me habia olvidado de eso jeje.

Lo del tiempo de instrucción y los calculos del timer voy a tener que repasar la hoja de datos como decis, son cosas que se me olvidan muy facil 

Mi configuracion es así

Código: [Seleccionar]

        #pragma config PLLDIV   = 5         // (20MHz crystal)
        #pragma config CPUDIV   = OSC1_PLL2   
        #pragma config USBDIV   = 2         // Clock source from 96MHz PLL/2
        #pragma config FOSC     = HSPLL_HSLuego calculo bien el TCY, aunque si alguien lo calculara o me diera una ayudita no me ofendo 

Veo que programas en C18. Yo pienso hacerlo en CCS. La configuración de los fuses se ve bien, es la misma que uso yo en mis proyectos con USB

Igual todavía no me quiero meter con el código hasta que tenga el hardware listo. Estoy pensando que me puedo estar olvidando, para luego no arrepentirme cuando tenga la placa ya hecha (pasa mas seguido de lo q parece). Hasta ahora tengo los pines para los servos, un puerto para la programacion en circuito, USB, un par de leds de estado, y no se si poner un pulsador, o entradas para sensores ultrasonicos... Para el modulo bluetooth tengo q hacer una adaptacion de niveles de tension, eso esta pendiente.
Que creen que se me puede estar olvidando??
Saludos!

[willynovi]

Hasta ahora tengo los pines para los servos, un puerto para la programacion en circuito, USB, un par de leds de estado, y no se si poner un pulsador, o entradas para sensores ultrasonicos... Para el modulo bluetooth tengo q hacer una adaptacion de niveles de tension, eso esta pendiente.
Que creen que se me puede estar olvidando??

Si optas por un bootloader USB vas a necesitar un pulsador para entrar en modo bootloader.
El bootloader Serie no lo conozco, así que no se que necesitarias, lo mismo que si fuera por bluetooth.

Yo cuando hago alguna placa siempre dejo todos los pines disponibles y con una linea de pines a GND por si hubiera que jumpearlos para no usarlos.
Si fuera algo específico, por ejemplo una entrada analógica, le dejo un pin a GND y otro a +5V. Siempre un pin a GND y otro a +5V cerca de un grupo de entradas/salidas del micro.
Tengo esa costumbre porque hago placas muy genéricas, como si fueran entrenadoras.

Por el tema de los Led o pulsadores quizas te conviene poner algún jumper por si mas adelantes tuvieras que disponer como entrada/salida para otra aplicación.
Por lo que alcancé a ver tienes lugar de sobra en el PCB que estas diseñando.

Vi que un par de rutas no te quedaron bien dibujadas o las dejas así con un propósito? Por ejemplo el GND del USB.