Robot equilibrista

[gera]

Buenas! Paso a contarles las ultimas noticias. Resulta que le escribi al compadre que hizo el zigroller y me ayudo bastante.

Resulta q cometi muchisimos errores (como yo sospechaba, en la lectura de los sensores). Vamos por partes como dijo jack el destripador:

1- Yo calibre el gyro experimentalmente, integrando su lectura para obtener el angulo, y comparando este con el calculado por el acelerometro. Pero resulta que cuando el robot esta en modo debug (graficando), el periodo de muestreo sube a unos 30ms (probablemente por el printf). Entonces el calculo del angulo era correcto solo cuando estaba graficando, de otro modo era erroneo. Esto pude comprobarlo cambiando el estado de un pin cada vez que tomaba las muestras y mirando en el osciloscopio.

2- La frecuencia de muestreo que yo estaba utilizando era de 50Hz, esto se debe a que una version mas vieja del robot usaba como gyro el LY530ALH que tenia un ancho de banda de 140Hz. Pero el gyro que uso ahora (IDG-500) es de 1KHz y tiene un filtro pasabajo con frecuencia de corte de 140Hz. Por lo tanto la frecuencia de muestreo tiene q ser al menos el doble de eso (por el teorema de Nyquist, para evitar aliasing). Lo ideal serian 400Hz.

3- Tambien estaba utilizando la salida amplificada del gyro que tiene un rango dinamico de +-110º/s. Es demasiado sensible, y cuando el robot da uno de esos golpes, puede que se sature. Asique ahora voy a utilizar la salida normal que tiene un rango de +-500º/s.
4- Mi codigo es muy complejo, para calcular el angulo utilizo el arcotangente, mas la linea de comando, el modo grafico etc... pierdo valiosos milisegundos. Por lo tanto pienso simplificar el codigo al maximo eliminando todas esas cosas inutiles.

Bueno, eso es todo. Dispongo de muy poco tiempo, por lo tanto no pude hacer esas correcciones, pero de a poco.

Saludos y espero q a alguno le sirvan mis errores para no cometerlos jeje.

[rivale]

Hola gera, que bueno que ya tienes por donde continuar, ahora que lo mensionas yo tambien tuve ese problema con el muestreo. tuve que medir los tiempos para saber excataqmente cuanto tardaba cada cilo. para esto use el isis.

Pues a seguir adelante, que aun nos falta hacer que se mueva libremente!!

[marito]

Hola Gera,yo también estoy trabajando sobre un robot equilibrista.

Con respecto al cálculo de la medición con el giro, realizo la medición del tiempo de ciclo en cada uno de estos, de este modo independizo esta variable de las posibles modificaciones que realice en el programa. Actualmente, utilizando un PIC16F876A a 20 MHz, y comunicando via serie valores a una pc para graficar, tengo un tiempo medio de ciclo de 25mseg (medidos en simulador y con osciloscoipo). Estoy trabajando en un nuevo circuito de control en el cual voy a usar un PIC18F4550 para tratar de reducir el tiempo de ciclo trabajando a 48MHz.

En lo que tiene que ver al cálculo del ángulo con el acelerómetro, comencé usando la medición de dos ejes integrando las mismas con el arcotangente; pero este cálculo  aumentaba demasiado el tiempo de ciclo. Por lo cual actualmente estoy usando directamente un solo eje, perpendicular a la estructura del robot. Obtuve mejores resultados con un solo eje que con el arcotangente de dos.

Hasta el momento, he conseguido que el robot se mantenga en pie, pero se desplaza demasiado. Por lo cual, mi idea es reducir el tiempo del ciclo de control cambiando el PIC como te mencionaba, y por otro lado, utilizar la lectura de los encoders de los motores de las ruedas para implementar un segundo lazo de control del desplazamiento de la estructura.

Espero que mi info pueda ser util en algo.

Saludos

[rivale]

creo que seria mejor tener un tiempo de muestreo fijo. pon un video de tu robot para ver que tanto se desplaza tu robot, yo tengo un tiempo de muestreo de 10 ms y lo puedo bajar hasta 2m usando un 4550

[marito]

Hola Rivale, este finde preparo un video.

Cual es el tiempo de ciclo de tu programa? Con el PIC16F876A que estoy usando hasta ahora no logré bajar el ciclo de mi programa de los 25mseg, con comunicación serie incluida.Ya tengo casi todo listo para montar la placa con el 4550 para tratar de bajar estos tiempos. Te parece que se puede mejorar la estabilidad con una variación de +- 15mseg en el ciclo de control?

Que beneficio tiene hacer el muestreo del giro con un ciclo fijo? Porque se estaría enviando una referencia poco fiable a los motores en caso de que el ciclo de programa sea menor al tiempo de muestreo o se estarían tomando muestras en vano en caso de que el ciclo de programa sea mayor al de muestreo. Estás de acuerdo?

Saludos!

[rivale]

yo lo que hago es que cada que tomo una muestra realizo el codigo del controlador y del filtro, es decir solo despues de cada muestra cambio la velocidad de los motores. yo logre un tiempo de muestreo de 10 ms ya con la comunicacion rs232 incluida, envio 2 flotantes hacia la pc, sin el envio de datos mi tiempo lo puedo bajar hasta 2[ms]

[gera]

Marito, si tu robot mantiene el equilibrio, creo que no es necesario aumentar el tiempo de muestreo ni nada, solo con implementar el otro lazo de control con los encoders se va a quedar quieto.
A mi el tiempo de muestreo me aumenta muchisimo cuando uso el puerto serie porq envio varios flotantes y en un formato especial para despues poder graficar. Pero necesito graficar para calibrar el gyro. Tal vez eso de medir el tiempo que toma cada ciclo de muestreo me ayude, de modo que cuando no necesite graficar mas, no varie la medicion del gyro. Como haces para medir ese tiempo? usas un timer?
Espero el video

[marito]

Hola Gera,

Para graficar conseguí una aplicación de excel a la que envio los datos que quiero graficar(como máximo 3). Lo bueno es que con un printf y la aplicación de excel ya estoy viendo los valores ingresados directamente en una tabla excel, no se como estas graficando vos?

Para calcular el tiempo de ciclo de programa, uso el timer0 y la función get_timer0.

Con respecto a cambiar el micro, uno de los motivos es tratar de reducir los tiempos y por otro lado, con el PIC16F876A no he conseguido leer los valores actuales de los encoders, tengo la placa MD25 comunicada vía I2C. Los ejemplos que se pueden conseguir están hechos con el PIC18F4550, por lo que vale la pena el intento.

Saludos!

Queda pendiente que suba el video!

[rivale]

la tarjeta md25 se comunica via i2c, para esto solo necesitas cualquier micro con ese protocolo, no es necesario un 18F

[marito]

Si, actualmente la estoy comunicando con un 16F876A, le puedo enviar la referencia pero no puedo leer los encoders, y como los ejemplos de la web del proovedor están echos para un 18F4550, decidi cambiar el micro.

[gera]

como estas graficando vos?

Yo grafico con un programita q hice en processing. Esta bueno porq eso me permite manipular la señal en la PC. En las primeras pruebas mandaba la señal en bruto del micro y en la PC aplicaba los filtros y eso.

Para calcular el tiempo de ciclo de programa, uso el timer0 y la función get_timer0.

Con ese timer0 solo podes medir 65.536 ms cierto? Utilizas la interrupcion para saber si te excediste de ese tiempo?

Con respecto a cambiar el micro, uno de los motivos es tratar de reducir los tiempos y por otro lado, con el PIC16F876A no he conseguido leer los valores actuales de los encoders, tengo la placa MD25 comunicada vía I2C. Los ejemplos que se pueden conseguir están hechos con el PIC18F4550, por lo que vale la pena el intento.

Podrias utilizar el pic16f877a que es muy similar al 876 y tiene i2c. Si programas en CCS, podes usar i2c por software.

Saludos!

[marito]

Gera,

Con ese timer0 solo podes medir 65.536 ms cierto? Utilizas la interrupcion para saber si te excediste de ese tiempo?

El tiempo que podés medir con el Timer0 depende del preescaler que utilices; yo configure el mío en 128, entonces el tiempo con cada desbordamiento del Timer0 (256 instrucciones) es : 256*256*4/20MHz. Con cada desbordamiento incremento un contador.
Ahora, cada instrucción, tiene un tiempo de 256*4/20MHz, cada vez que quiero calcular el tiempo con la función gettimer0 conozco cuantas instrucciones van ejecutandose hasta el momento. Entonces del tiempo de instruciones sumado al tiempo de desbordamientos del timer0, obtengo el tiempo de mi ciclo de programa.

Espero haber sido claro.

Por otro lado, aclaro que estoy usando la comunicación I2C con el PIC16F876A, pero no logre leer los encoders, si logre controlar los motores

Saludos.

[gera]

Clarisimo, muchas gracias Marito!!
Con respecto a los encoders, cual es exactamente el problema? los probaste fuera de la placa con un osciloscopio para ver si funcionan?

[rivale]

Con respecto a los encoders, cual es exactamente el problema? los probaste fuera de la placa con un osciloscopio para ver si funcionan?

el problema no creo que sean sus encoders, esta usando una tarjeta controladora de motores, que esta hecha con un pic presisamente jeje. me parece que el problema es al leer los datos, tendrias que checar como estas enviando la direccion y la lectura del registro de los encoders.

[Diego Gonzalez]

Excelentisimo tema. Me lo he tragado nuevamente desde sus inicios

A ver Nocturno si te da por acabar el pobrecito bicho que te mira con carita de pena desde el cajon.

Y mi admiracion por los desarrollos aqui mostrados. son increibles.

Hace meses que me he metido de nuevo con la electronica, y he decidido probar sensores y sensores, a la par que seguir aprendiendo programacion, protocolos etc, y es por eso que en su dia lei este tema, pero ahora lo releo con mas interes, ya que me entero de bastantes mas terminos que antes

En mis pruebas con el giroscopo, acuso una deriva muy grande, diferencias de aceleracion angular implican calculos de giro erroneos que acumulan error. Aun no le he puesto un aclerometro para aplicar filtros, pero una pregunta basica. ¿que tasa de muestreo se suele emplear en estos robots, o el segway, etc? De momento lo hago por interrupciones exactas del timer, pero no sé. son mis primeros pasos

Un afectuoso saludo