Autor Tema: Robot Hexapodo  (Leído 56028 veces)

0 Usuarios y 2 Visitantes están viendo este tema.

Desconectado gera

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 2188
Re: Robot Hexapodo
« Respuesta #75 en: 27 de Diciembre de 2012, 21:18:14 »
Gera, estoy viendo de adquirir un módulo Bluetooth, vos ya tenes uno, o estas pensando adquirir ese del link?
En cualquiera de los dos casos, cual viene mejor? Se que algunos son mas funcionales que otros.

Tengo varios modulos. Entre ellos un JY-MCU (el del link) y un RN-41. El primero tiene la ventaja que de que sale 8 dolares aprox, y funciona con 5V. El RN-41 es bastante mas caro (yo lo compre a sparkfun) y funciona con 3.3V, por lo tanto necesita adaptacion de tensiones. Sin embargo lo he probado bastante y funciona de 10. Con el JY-MCU no he hecho pruebas aun.

Hola gera.
Una consulta.¿ El LVD lo haces con la entrada V_sens ?
Saludos

Exacto. Busca en la hoja de datos del PIC, en la seccion de HLVD. Podes configurarlo de varias maneras. Te permite sensar la misma tension de alimentacion del PIC, o una tension externa que entre por el pin RA5/HLVD. En mi caso, utilizo un divisor resistivo para saber cuando la tension de la bateria baja de los 10,2V. Cuando ocurre eso, se activa una interrupcion.

Saludos!!

"conozco dos cosas infinitas: el universo y la estupidez humana. Y no estoy muy seguro del primero." A.Einstein

Desconectado Miquel_S

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1251
Re: Robot Hexapodo
« Respuesta #76 en: 28 de Diciembre de 2012, 03:50:33 »
Hola willynovi, lo de los transistores no es para el control de los servos, ahí no tengo problemas, seria en la fuente de alimentación a la salida del integrado para aumentar la corriente para alimentar dichos servos.

Saludos!
Todos somos muy ignorantes. Lo que ocurre es que no todos ignoramos las mismas cosas.

Desconectado gera

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 2188
Re: Robot Hexapodo
« Respuesta #77 en: 28 de Diciembre de 2012, 09:30:25 »
Hola willynovi, lo de los transistores no es para el control de los servos, ahí no tengo problemas, seria en la fuente de alimentación a la salida del integrado para aumentar la corriente para alimentar dichos servos.

Saludos!

Ahhh ahora entiendo jeje. Si, podes ponerle un transistor a un regulador para sacarle mas corriente. Pero yo te recomiendo un regulador switching. Son mas eficientes, disipan menos calor y entregan bastante corriente :wink:

"conozco dos cosas infinitas: el universo y la estupidez humana. Y no estoy muy seguro del primero." A.Einstein

Desconectado willynovi

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 546
Re: Robot Hexapodo
« Respuesta #78 en: 30 de Diciembre de 2012, 19:30:06 »
Algunas pruebas que hice, con los pocos servos que tengo en casa (4), que incluso la prueba la hago con solo uno  :lol:

Lo que estoy descubriendo es que tengo un problema de ruido, como llego a esa conclusión?

Resulta que hice un programita que atiende las posición de los servos, cantidad 18 hasta ahora porque estoy con el 18f2550, pongo posiciones fijas de a saltos de 10 grados para probar el movimiento de cada servo, es decir, algo así:

Servo[0] = 100
Servo[1] = 90
Servo[2] = 80
.......

osea cada salida tiene ese valor fijo y no lo actualizo en ningún momento.

Y con el mismo servo voy conectando a las distintas salidas que tengo definidas como los servos.

Aparentemente la atención a los servos anda bien porque cuando cambio de una salida a la otra el servo cambia su posición en esos 10 grados de giro, hasta ahí venimos bien.

Pero resulta que el programita que enviaría los datos por el USB se queda tildado, al parecer como que pierde la comunicación con la placa al filtrarse algo de ruido por la conexión y desconexión del servo.

El programita que utilizo es el que provee como ejemplo Microchip, "HID PnP Demo.exe"
Este programita censa el estado de un switch y en algun momento deja de mostrarme el estado, lo que me indica que ha perdido la comunicación.

Ahora, mientras no conecto el servo el programa se mantiene funcionando correctamente.

Les comparto las partes del código donde atiendo a los servos, principalmente es la rutina de la interrupción por TMR0. La base del código es del ejemplo de gu1llermo, o sea generando una interrupción cada 0,04 mseg, lo que me da una resolución de 50 pasos. En breve pruebaré con 100 a ver que hace  ;-)

Código: [Seleccionar]
/** CONSTANTS ******************************************************/
#define left 65160 // TMR0 Value for 0,5 msec
#define right 52410 // TMR0 Value for 17,5 msec
#define middle 65505 // TMR0 Value for 40 usec (0,04 msec)

Código: [Seleccionar]
void YourHighPriorityISRCode()
{
//Check which interrupt flag caused the interrupt.
//Service the interrupt
//Clear the interrupt flag
//Etc.
if(INTCONbits.TMR0IF)
{
// Rutine to serve all servos
// it has to last 2 msec, if first 0,5 msec are driven by TMR0 interrupt, else 2,5 msec
if(Fase == 52)
{
WriteTimer0(left); // Timer for 0,5 msec
mSERVO_All_On(); // At 0,0 msec all servo pin must go ON
Fase = 0;
INTCONbits.TMR0IF = 0; // Clear interrupt flag
}
if((Fase >= 0) && (Fase < 51))
{
WriteTimer0(middle); // Timer for 20 usec
if (Servo[0] == Fase){mSERVO_0_Off();} // If servo pos < Fase then servo pin OFF
if (Servo[1] == Fase){mSERVO_1_Off();}
if (Servo[2] == Fase){mSERVO_2_Off();}
if (Servo[3] == Fase){mSERVO_3_Off();}
if (Servo[4] == Fase){mSERVO_4_Off();}
if (Servo[5] == Fase){mSERVO_5_Off();}
if (Servo[6] == Fase){mSERVO_6_Off();}
if (Servo[7] == Fase){mSERVO_7_Off();}
if (Servo[8] == Fase){mSERVO_8_Off();}
if (Servo[9] == Fase){mSERVO_9_Off();}
if (Servo[10] == Fase){mSERVO_10_Off();}
if (Servo[11] == Fase){mSERVO_11_Off();}
if (Servo[12] == Fase){mSERVO_12_Off();}
if (Servo[13] == Fase){mSERVO_13_Off();}
if (Servo[14] == Fase){mSERVO_14_Off();}
if (Servo[15] == Fase){mSERVO_15_Off();}
if (Servo[16] == Fase){mSERVO_16_Off();}
if (Servo[17] == Fase){mSERVO_17_Off();}
Fase++;
INTCONbits.TMR0IF = 0; // Clear interrupt flag
}
if(Fase == 51)
{
WriteTimer0(right); // Timer for 17,5 msec
Fase++;
INTCONbits.TMR0IF = 0; // Clear interrupt flag
}

}
#if defined(USB_INTERRUPT)
USBDeviceTasks();
#endif

} //This return will be a "retfie fast", since this is in a #pragma interrupt section

Código: [Seleccionar]
OpenTimer0(TIMER_INT_ON & T0_16BIT & T0_SOURCE_INT & T0_PS_1_16);
INTCON2bits.TMR0IP = 1; // High priority for Timer0
RCONbits.IPEN = 1; // Enable priority levels
INTCONbits.GIEH = 1; // Enable interrupts
WriteTimer0(1785); // Timer for 85 msec -> only for first interrupt

Lo siguiente es modificar un poco el programa host (en la PC) para poder enviar los datos de los servos y poder variar la posición de cada uno, por el momento con un simple valor manejado con un control slide.
Intento enseñarte a pescar, si solo quieres pescados, espera que un pescador te regale los suyos.

Desconectado gera

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 2188
Re: Robot Hexapodo
« Respuesta #79 en: 31 de Diciembre de 2012, 00:56:45 »
Willy, bien ahi por los avances!!
Probaste alimentar los servos con una fuente separada? Seguramente cuando lo conectas, hay un consumo que hace caer la tension de alimentacion y el pic se reinicia. Proba con una fuente aparte (compartiendo masas obvio).

"conozco dos cosas infinitas: el universo y la estupidez humana. Y no estoy muy seguro del primero." A.Einstein

Desconectado willynovi

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 546
Re: Robot Hexapodo
« Respuesta #80 en: 31 de Diciembre de 2012, 11:29:26 »
Por ahora estoy alimentando todo desde el USB de la netbook porque tenia un solo servo para pruebas, fue algo improvisado solo para probar el código.
Cuando vuelva con las pruebas los alimento con una fuente independiente, obvio con masas compartidas  ;-)

Es lo que sospecho, que sea problema de ruido o alimentación que hace reiniciar al PIC, como los valores de los servos son fijos no logro diferenciar si el PIC se esta reiniciando.

Luego les adjunto el proyecto completo por si alguien le quiere meter mano  ;-)
Intento enseñarte a pescar, si solo quieres pescados, espera que un pescador te regale los suyos.

Desconectado Suky

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 6758
Re: Robot Hexapodo
« Respuesta #81 en: 31 de Diciembre de 2012, 12:21:54 »
Si desconectas todos los servos (de esa manera no se genera ruido) funciona la comunicación? Porque puede ser falta de atención a la comunicación debido al corto periodo que existe entre interrupciones.

Usas polling o interrupt?

Saludos!
No contesto mensajes privados, las consultas en el foro

Desconectado gera

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 2188
Re: Robot Hexapodo
« Respuesta #82 en: 31 de Diciembre de 2012, 13:33:43 »
Creo que hay un registro del micro que te dice cual fue la causa del ultimo reset. Tendrias q consultarlo a ver si es por "brownout". En ese caso, es porque cayo la tension.

Si desconectas todos los servos (de esa manera no se genera ruido) funciona la comunicación? Porque puede ser falta de atención a la comunicación debido al corto periodo que existe entre interrupciones.

Usas polling o interrupt?

Saludos!

Suky, yo entendi que la comunicacion funciona, hasta que conecta el servo. Estoy casi seguro que es el consumo del motor lo que hace que se reinicie, pero mejor esperemos a que responda Willy.

Por cierto, como implementas polling en el micro?

Saludos!

"conozco dos cosas infinitas: el universo y la estupidez humana. Y no estoy muy seguro del primero." A.Einstein

Desconectado willynovi

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 546
Re: Robot Hexapodo
« Respuesta #83 en: 31 de Diciembre de 2012, 14:06:03 »
Termino de hacer unas pruebas como para descartar la posible raiz del problemas, y creo que he llegado a una conclusión, que es por baja de la tensión al conectar el servo o por el ruido del motor del servo.

La prueba que hice fue cambiar el servo por un simple LED y no he tenido problemas de comunicación, conecto y desconecto el LED a todas las salidas y nunca pierdo la comunicación.

Suky, estoy usando "polling", probé con "interrupt" pero noté algunos problemillas, tampoco investigué mucho.

Gera, estoy trabajando con el framework de Microchip, el polling o interrupt lo selección con un #define, la verdad no investigué como está implementado.

Despues hago mas pruebas alimentando los servos con otra fuente.
Intento enseñarte a pescar, si solo quieres pescados, espera que un pescador te regale los suyos.

Desconectado MGLSOFT

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 7912
Re: Robot Hexapodo
« Respuesta #84 en: 31 de Diciembre de 2012, 19:21:57 »
Yo tuve una placa en comunicación a la PC, transmitiendo a 115200 Bps y pasaba algo parecido a lo que dices.
Uso un FT232RL y en ese momento se alimentaba desde la placa, compartiendo el regulador y la masa, ademas de los pines TX y RX del micro.

Se soluciono reprogramandolo para que tome tensión del puerto USB y la placa sigue alimentándose desde su propia fuente, ahora solo comparte la masa y los pines de comunicación.
Llegue a transmitir a 460800 bps sin un solo mensaje erróneo, y sin usar las lineas de control de flujo.
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado willynovi

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 546
Re: Robot Hexapodo
« Respuesta #85 en: 31 de Diciembre de 2012, 19:32:12 »
No entendí mucho tu aplicación, si es USB a la PC o por puerto serie tradicional.

De todas formas creo que el problema está en la alimentación como decis vos, ademas que la idea no es alimentar todos los servos desde el USB de la PC, estoy limitado en corriente así que no es un problema tener que usar otra fuente ya que era algo que iba a hacer.

Ahora estoy en pleno desarrollo de la aplicación Host, así que por unos días no voy a estar probando mucho  :oops:
Intento enseñarte a pescar, si solo quieres pescados, espera que un pescador te regale los suyos.

Desconectado MGLSOFT

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 7912
Re: Robot Hexapodo
« Respuesta #86 en: 01 de Enero de 2013, 21:35:27 »
Mi transmicion es serial >> Adaptador USB.
Para lo que te daba el ejemplo es para decirte que el USB no alimenta mas de 120 mA por el puerto, y que es muy afectado por los ruidos eléctricos y otros temas que lo perturban.
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado willynovi

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 546
Re: Robot Hexapodo
« Respuesta #87 en: 02 de Enero de 2013, 17:53:36 »
Mi transmicion es serial >> Adaptador USB.
Para lo que te daba el ejemplo es para decirte que el USB no alimenta mas de 120 mA por el puerto, y que es muy afectado por los ruidos eléctricos y otros temas que lo perturban.
Si eso sospecho, como te pasó a vos, lo mas probable es que tenga ruido que afecte y se reinicie el programa, mas que nada por la prueba que hice con el LED.
Por el tema de que se pase de corriente, creo que todavía no me ha pasado porque creo que la PC me hubiera avisado, al menos una vez me avisó cuando tuve un corto en otra placa y si mal no recuerdo se reinició la compu.

Cuando tenga el soft que envia datos seguro que lo voy a confirmar.

Hablando de eso, del soft que envia datos, no soy un programador muy experimentado, lo que mas he hecho es muy simple.
La pregunta concreta es, es necesario que al enviar una trama de datos, primer byte para un código y luego 20 bytes mas para la posición de cada servo, el dispositivo con el que me estoy comunicando retorne algún byte?
Entiendo que si tengo algún sensor, por ejemplo un switch, es necesario saber el estado, pero si no tuviera, es buena práctica usar un retorno desde el dispositivo? por ejemplo un código "estoy vivo" o "recibí los datos bien"
Intento enseñarte a pescar, si solo quieres pescados, espera que un pescador te regale los suyos.

Desconectado Darkman_A

  • PIC18
  • ****
  • Mensajes: 288
Re: Robot Hexapodo
« Respuesta #88 en: 02 de Enero de 2013, 23:46:29 »
Mi transmicion es serial >> Adaptador USB.
Para lo que te daba el ejemplo es para decirte que el USB no alimenta mas de 120 mA por el puerto, y que es muy afectado por los ruidos eléctricos y otros temas que lo perturban.
Si eso sospecho, como te pasó a vos, lo mas probable es que tenga ruido que afecte y se reinicie el programa, mas que nada por la prueba que hice con el LED.
Por el tema de que se pase de corriente, creo que todavía no me ha pasado porque creo que la PC me hubiera avisado, al menos una vez me avisó cuando tuve un corto en otra placa y si mal no recuerdo se reinició la compu.

Cuando tenga el soft que envia datos seguro que lo voy a confirmar.

Hablando de eso, del soft que envia datos, no soy un programador muy experimentado, lo que mas he hecho es muy simple.
La pregunta concreta es, es necesario que al enviar una trama de datos, primer byte para un código y luego 20 bytes mas para la posición de cada servo, el dispositivo con el que me estoy comunicando retorne algún byte?
Entiendo que si tengo algún sensor, por ejemplo un switch, es necesario saber el estado, pero si no tuviera, es buena práctica usar un retorno desde el dispositivo? por ejemplo un código "estoy vivo" o "recibí los datos bien"

Hola willy.
A tu consulta de si  es buena práctica usar un retorno desde el dispositivo? por ejemplo un código "estoy vivo" o "recibí los datos bien" pienso que si, siempre y cuando la utilices. A veces se implementan y luego no se utilizan asi que es como si no existiera esta caracteristica. Una de las cosas que te puede devolver el dispositivo es un check sum de lo que ha recibido. Asi podrias verificar si los datos que le has enviado han llegado bien y en particular si "se han interpretado" bien. Imaginate que tenes inconveniente de ruido como supones te esta ocurriendo ahora. Cuando le envies datos al robot este haria cualquier cosa o no funcionaria. Con solo realizar la verificacion del check sum te darias cuenta. Por ejemplo, uno de los elementos que suelen dar problema son los cables USB.
Por otra parte tambien podrias tener algun codigo en la trama de datos que indique que estas haciendo una actualizacion de algun servo en particular (o de un grupo de servo) asi le podrias enviar los datos de los servos que cambian de posicion y no la de los 20 servos. Algo asi como

      -------------------------------------------------------------------------------------------------------------------
     | id inicio | id cambio parcial | servo5 | posicion | servo 7| posicion | servo11 | posicion | CRC | FIN |
     --------------------------------------------------------------------------------------------------------------------
id: identificador

Fijate si te cierra la idea.

Saludos.
« Última modificación: 02 de Enero de 2013, 23:49:42 por Darkman_A »

Desconectado willynovi

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 546
Re: Robot Hexapodo
« Respuesta #89 en: 03 de Enero de 2013, 00:22:18 »
Gracias por el aporte, y te comento que todavía estoy viendo como voy a enviar las posiciones de los servos.
Justo hoy estaba pensando en que quizás al enviar la posición de todos los servos en muchos casos voy a enviar datos de mas con lo que incremento la posibilidad de errores en la transmisión.
Entonces justamente pensaba eso que planteas vos, enviar solo la posición de los servos que han cambiado, y el resto dejarlos como están, ya que al no recibir datos de actualizar posición, mantendrían la posición actual.
Creo que algo de esto ya había planteado Gera.

Ademas es necesario tener en cuenta la inercia mecánica, de que sirve enviar datos si el robot no tiene posibilidad de procesarlos.

Lo del "check sum" lo he escuchado pero no he investigado mucho como implementarlo, aunque no creo sea difícil implementarlo  ;-)

Se que en muchos temas me adelanto, pero es como que tengo una forma de encarar las cosas un poco desordenada o como que voy avanzando distintos conceptos a la vez, así ya los voy madurando desde temprano  8)
Espero no desvirtuar el hilo Gera  :oops:
Intento enseñarte a pescar, si solo quieres pescados, espera que un pescador te regale los suyos.


 

anything