Cómo haríais el tema de acelerar y frenar en recta que es vital para los concursos, acabamos de empezar con ello y la idea que tenemos es acelerar al máximo al principio de recta durante X espacio, una vez transcurrido esa distancia frenar durante x pulsos a una velocidad muy baja, para pasar a la velocidad de entrade a curva.

De momento hemos conseguido poner el PWM al 100% en recta durante un tramo y que el robot aguante en la pista, pero queda mucho que probar y ajustar para conseguir aprovechar las rectas al máximo como hacen alguno de los robots de los concursos.

Led en verde PWM al 100%: http://www.youtube.com/watch?v=OGRImyTVV9Q " onclick="window.open(this.href);return false;

El tema de las constantes y combinaciones se multiplica, aquí ya se echa en falta llevar otro tipo de sensores como acelerómetro o giróscopo, para la siguiente versión hay que ponerlos.

Cómo lo haría yo: enconders en las ruedas, PID por interrupción, con una variable global para consulta sobre la diferencia de velocidad de las ruedas, y así poder saber cuanto giras.

Determinas que sales de una curva cuando la diferencia baja de determinado valor. Aceleras al 90-95% (para tener margen de seguir la línea). Cuentas cuantos pulsos llevas de recta, y comparas respecto de un valor más o menos conocido de pulsos totales de la recta. Cuando falte X, frenas de tal manera que estés a la velocidad prevista para la curva un poco antes de esta, y entonces comparas con el valor de diferencia de velocidad para saber que has entrado en la curva.

Si lo haces bien, puedes apurar la frenada mucho, incluso entrar frenando en la curva.

Por cierto, ¿alguien ha probado a ejecutar el PID por pulsos de rueda en lugar de por tics del timer?

Cómo lo haría yo: enconders en las ruedas, PID por interrupción, con una variable global para consulta sobre la diferencia de velocidad de las ruedas, y así poder saber cuanto giras.

Determinas que sales de una curva cuando la diferencia baja de determinado valor. Aceleras al 90-95% (para tener margen de seguir la línea). Cuentas cuantos pulsos llevas de recta, y comparas respecto de un valor más o menos conocido de pulsos totales de la recta. Cuando falte X, frenas de tal manera que estés a la velocidad prevista para la curva un poco antes de esta, y entonces comparas con el valor de diferencia de velocidad para saber que has entrado en la curva.

Si lo haces bien, puedes apurar la frenada mucho, incluso entrar frenando en la curva.

Por cierto, ¿alguien ha probado a ejecutar el PID por pulsos de rueda en lugar de por tics del timer?
Así exactamente lo tenía hecho. Pero con las ruedas esas tochas el robot no respondía nada bien (aun no le había pillado las constantes correctas, supongo) y como iba cabeceando todo el rato no me servía de nada todo eso y preferí ponerle las finitas y funcionar sin encoders porque no me daba tiempo a preparar uno para las finitas.
Incluso tenía hecho que reconociera donde estaban las curvas intermedias para hacerlo todo recto. Aquí me encontré con el problema que como el robot no iba estable y los motores responden un "poco" diferente al mismo pwm, al intentar hacer el tramo recto el robot se torcía (a veces a un lado, a veces a otro, a veces mucho, otras menos,... Aquí un sensor inercial/posicional ayudaria bastante). Que si se que el robot va a una velocidad fija lo puedo corregir por software, pero como estaba de pruebas cambiando velocidades, no funcionaba bien. Lo suyo sería un control de velocidad, cosa imposible con un encoder a la rueda por lo lento de los pulsos. Poner un encóder en el motor es lo suyo, pero o me gasto 200€ por motor o me complico bastante mecánicamente (pololu tiene motores con eje trasero para eso) o me meto con los brushless y me complico electrónicamente.

Contar el tiempo entre pulsos de encóder directamente te da la inversa de la velocidad, cosa que está bien. A altas velocidades puedes usar un timer directamente y tendrás la variación de velocidad bastante bien. Pero cuando la velocidad baja, ya tienes que tener en cuenta cuantas veces ese timer se ha desbordado y eso implica más cálculos. De todos modos para el velocista ya me he decidido hacerlo con un micro que tiene dos entradas hardware de encóder, así me olvido directamente de esas interrupciones/timer y solo tengo que leer el registro correspondiente. Este año solo encóder a la rueda y sin control de velocidad, eso si da tiempo de terminar el robot.

Veo que (como siempre) me he explicado mal en la última pregunta de mi anterior post.

La respuesta sobre cómo medir la velocidad es impecable, pero no me refería a eso.

Quería preguntar cómo haceis el control PID. Me imagino que en un timer que salta cada cierto tiempo fijo (es cómo lo hago yo!!), se ejecuta la rutina de control de PID, recalculando lo necesario. Eso implica que la corrección depende del tiempo, y es fija. Pero el sistema no responde igual según la velocidad, así que igual hay que cambiar las constantes del PID según a que velocidad se corre. Por eso, lo que preguntaba yo, es si alguien, en lugar de ejecutar el PID cada x milisegundos, ejecuta el mismo a cada n pasos de la vuelta, con lo que los cálculos de PID se hacen sobre los metros recorridos, no sobre el tiempo, independizando así el control de la velocidad final del robot.

Es una prueba que me gustaría hacer algún día. Pero es que no tengo tiempo ni para ver la tele...

En teoría, si el regulador PID es convencional, la Kp (constante proporcional),la Ki (constante inegral) y la Kd (constante derivativa) son independientes una de otra. Pero si son dependientes del tiempo de muestreo, (cada cuantos ms ejecutas la rutina del PID). Si lo cambias has de recalcular Kp, Ki, Kd.
Además son específicas para una aplicación (función de transferencia), independiente de las variables de entrada.
Esto significa que el PID debería trabajar igual a baja que a alta velocidad, con las mismas constantes. Solo es necesario cambiar esas constantes si se varía la función de transferencia del sistema, por ejemplo se aumenta la masa (mas inercia), se varía la potencia (proceso más rápido) etc.
A mi me ha pasado que, implementar mal un PID en C, las variables se interelacionaban. Pero no debería ser así.
Sintonizar un PID es bastante laborioso, si encima se interfieren unas constantes con otras entonces es imposible...
http://eie.ucr.ac.cr/uploads/file/documentos/pub_inv/articulos/valfaro02B.pdf " onclick="window.open(this.href);return false;
En la práctica se usan métodos de prueba y error: primero solo Kp. Cuando se tiene el sistema controlado pero lento se acelera con Ki. Con Kd se elimina el overshoot pero pueden producirse oscilaciones. http://en.wikipedia.org/wiki/PID_controller " onclick="window.open(this.href);return false;

Otro tema, para salivar: http://lcamtuf.coredump.cx/omni/ " onclick="window.open(this.href);return false;
Estupenda plataforma para robot, autoconstruida, manual de mecanizado CNC, uso de resinas y moldes etc...