Ranganok, a ver cuando pasas de la teoría a la práctica que no es lo mismo. Mira que solo queda un mes ya para AESS!

Bueno, gracias a JMN, creo que he descubierto otro error de programación o de concepto en mi robot. Y de paso quiero compartir con vosotros una duda que todavía tengo.

Cual os parece el mejor método para realizar el control de los motores, y porqué, de estos tres:

1) Frenar la rueda interior a la curva:
if(PID < 0) { VmotorIzq = Vcrucero+PID; VmotorDer = Vcrucero; }
else { VmotorIzq = Vcrucero; VmotorDer = Vcrucero-PID; }

2) Acelerar la rueda exterior a la curva:
if(PID < 0) { VmotorIzq = Vcrucero; VmotorDer = Vcrucero-PID; }
else { VmotorIzq = Vcrucero+PID; VmotorDer = Vcrucero; }

3) Hacer las dos cosas a la vez:
VmotorIzq = Vcrucero+PID; VmotorDer = Vcrucero-PID;

Alguien lo ha probado en su robot? A mi con el tercer método me oscilaba mucho el robot, se volvía muy "nervioso".

Los dos primeros frenan, y aplican una corrección de valor PID. El tercero, mantiene la velocidad media, pero aplica una corrección de 2 x PID, con lo que éste último será más nervioso por partida doble: más velocidad que los dos primeros, y una corrección con una ganancia el doble. Mi opinión es utilizar el segundo, pero reajustando los valores del PID adecuadamente.

Respecto de Nyquist, éste es impepinable. Sin discusión posible. Pero aún así, me gustaría hacer una reflexión: a los 4m/s a los que van actualmente los velocistas, y suponiendo un tic de cálculo del PID de 1ms, tenemos que entre cálculo y cálculo, el robot se ha desplazado 4mm. Y los motores, junto con la inercia, hace que la respuesta sea 'lenta', es decir, que aunque estemos por encima de Nyquist, el error se puede disparar relativamente rápido si la velocidad aumenta.

Si el robot varía la velocidad (como hacen actualmente) para pasar por curva, por ejemplo, a 1m/s, entonces tenemos que aunque la planta sea más o menos igual de lenta, tomamos una medida cada mm de recorrido, con lo que el error se acumulará a 1/4 parte de la velocidad a la que lo hacía, de tal manera que aunque la planta sea igual de lenta (me refiero a la velocidad de respuesta de los motores y el vehículo), la velocidad a la que se modifica el error no es igual. Con lo cual, aunque apliquemos Nyquist y nos den la misma frecuencia de muestreo en ambos casos, los resultados no van a ser los mismos. Es decir, que igual tenemos que aplicar Nyquist respecto de la velocidad del error (que depende de la velocidad del vehículo) en lugar de sobre la velocidad de respuesta de la planta.

Además, la resolución, en mi humilde opinión, que se gasta con los CNY70, e incluso con los QRE1113, es pobre, de ahí que haya que aumentarla de manera artificial, alargando tanto el morro.

Por eso, hace algún tiempo que pienso que puede ser interesante aplicar Kalman, y sensores con mayor resolución (tengo hecho, pero no probado, uno con 33 posiciones a 1.5mm). Eso sí: hace falta algo más de potencia de cálculo. Por ejemplo, un barato STM32f407...

No, el segundo método acelera la rueda contraria en vez de frenarla como hace el primer metodo. Y el tercer método me da a mi que la respuesta es mayor que hacer el doble del método uno, pero no he hecho ningún cálculo matemático y quizá me equivoque.

Me gustaría saber la impresión de alguien que lo haya probado en su robot. A mi el tercero me parecia demasiado inestable. Respecto de los dos primeros tendria que hacer mas pruebas, ya que usaba uno cuando creia que estaba con el otro.

Cierto, cierto, eso de que el segudo acelera. Eso me pasa por leer en diagonal...

Todo el mundo usa de salida la velocidad relativa de las ruedas, entonces hay un factor interpuesto entre el error y la salida que es la velocidad... Para que funcione debemos compensarlo: si el error es independiente de la velocidad la salida también debe serlo. Si el error depende de la velocidad la salida también debe depender.

Resumen: hay que diseñar correctamente el sistema para que sea posible controlarlo con un PID sencillo. Pasando por escoger adecuadamente las variables de entrada y salida. Hay que asegurarse de que entre la entrada y la salida hay una relación lineal (función de transferencia) independiente de otros factores.

Desde mis pocos conocimientos sobres estos temas coincido con lo que dices Heli, el problema es que la velocidad en nuestro sistema no es una variable de entrada, ni podemos medirla ni controlarla, ya que en estos robots no tenemos la opción de hacer un control de velocidad que integrar dentro del de posición, debido a que los encoders que llevamos valen para contar distancia pero no para hacer un control de velocidad.

Por lo que la "velocidad absoluta" en nuestro sistema pasa a ser una constante que establecemos en el programa y por tanto de la que depende la variación de la salida del sistema y de la que si depende su función de transferencia. Como dices lo único que podemos usar y controlar aquí es la velocidad relativa entre las ruedas y no la velocidad.

El tal nyquist aquí no tiene nada que ver en nuestro problema, ya que el tiempo de muestreo que usamos inicialmente ya es muy bajo y ya cumplimos con lo que dice (esto es lo primero que se tiene en cuenta al muestrear cualquier señal), ahora usamos 1 ms, aunque en su día hice pruebas con tiempos más bajos ya que al leer en digital se puede ejecutar la isr del tic de programa en muy poco tiempo.

Si alguien nos cuenta como ha hecho (no como hacer) un velocista sin encoders para que el ajuste del regulador sea independiente de la velocidad yo soy todo oídos. Por otro lado agradecería que las respuestas que se den en este hilo "robots para concursos" (y por tanto robots tangibles que hemos hecho o estamos haciendo para participar) sean desde la práctica y experiencia, ya que si no sólo pueden dar lugar a discusiones teóricas que probablemente no aporten nada a la gran mayoría de nosotros y sólo sirvan para perder el tiempo.

Para "lucirse" con la teoría, "la ingeniería" y las respuestas puede haber muchos otros hilos 😉

Desde mi experiencia y sobre el tema, copio del correo que le mandé ayer a dragonet y donde se intenta demostrar lo dicho, y ya de paso aprovecho para responderte aquí dragonet80.
Robot velocista a velocidad constante (sin acelerar y frenar en recta) alta:

http://www.youtube.com/watch?v=0tPXvoMG23I " onclick="window.open(this.href);return false;

El robot sigue bien la línea, si ahora bajamos la velocidad manteniendo las mismas constantes (donde pone un 16 en el video es un 15, son las mismas constantes que en el anterior):

http://www.youtube.com/watch?v=WwCl5vw-I20 " onclick="window.open(this.href);return false;

El robot también sigue la línea de forma correcta, no sé si se puede apreciar en el video pero tiene como una correción constante en el morro muy brusca, como si oscilase. El robot aquí tarda más de 7.26 segundos por vuelta.

Si ahora para la misma velocidad bajamos las constantes:

http://www.youtube.com/watch?v=QSYa8kdM2w4 " onclick="window.open(this.href);return false;

El robot tarda 5.8 s por vuelta. Son las primeras constantes que he puesto, la mitad de las anteriores, por lo que a lo mejor aún puede ir más rápido.

Si con las constates anteriores incrementamos la velocidad a la del primer video el robot se va fuera en la primera curva o incluso en la propia recta.

Al aumentar las constantes lo que haces es correr menos, el error lo multiplicas por las constantes, y el resultado se lo restas a la velocidad de cada motor para girar. Por lo que cuanto mayores sean las constantes menor va a ser la velocidad media. Si llevas las constantes muy altas el robot te va a oscilar, nada más que el primer o segundo sensor vean la línea el robot va a girar bruscamente, entrando en una especie de oscilación como no sé si se puede apreciar en el segundo video.

En tu caso que sumas el error dragonet, yo creo que el robot te va a ir cabeceando en la recta (y bastante más que en el caso de que si restas) ya que al mínimo error te va a corregir bruscamente, por lo que el espacio que recorres en la recta va a ser mucho mayor debido a la oscilación, lo que se traduce en una velocidad media menor que si el robot fuese en línea recta sin oscilar (menos espacio).

La forma de empeorar el tiempo (independientemente de la velocidad) es oscilar y derrapar en las entradas a las curvas.

Nosotros también hemos probado a sumar en un motor el error y restar en el otro ese error (caso 3), y el resultado fue peor que dejando un motor a la velocidad y restar en el otro el error (caso 1).

En el caso 1 decrementas la velocidad total del robot en la entrada a la curva, en el caso 2 la aumentas, y en el caso 3 la mantienes igual. Yo creo que la mejor forma de entrar en una curva es decrementar la velocidad total (es decir frenar la rueda interior), si antes de entrar a la curva aumentas la velocidad como estás haciendo no tiene mucho sentido, cuando vas en coche al llegar a una curva frenas (no aceleras).

Sin saber muy bien de lo que hablo, la rueda del robot tiene una fuerza de rozamiento máxima, y si estás acelerando al mismo tiempo que giras estás haciendo esa fuerza en dos ejes (incrementandola en ambos), por lo que desde mi punto de vista va a ser más fácil que derrapes.

A nosotros lo que mejor nos ha funcionado es el caso 1, al ver la curva decrementar la velocidad de la rueda interior para empezar a girar. Una vez que estamos en curva y el robot ha detectado que está en ésta seguirmos girando de la misma forma, pero aumentamos la constante de velocidad absoluta a una mayor (aún así la velocidad equivalente de los dos motores será menor que a la de recta, ya que sólo va al máximo en un motor) para que el robot gire más rápido (llevamos una velocidad de recta y otra de curva), pero el punto crítico que determina la velocidad creo que es la entrada a curva desde recta.

Saludos.