Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Hola a todos,
Me hago eco en este hilo de un comentario que salió en otro: Robots para concursos. Kits o lo que veais que pueda interesar al principiante, intermedio o experto.
Esto es lo que JMV comentaba :
Hablando de minisumo (y por hablar un poco de robots para concursos en este foro.. ¬¬) on enlazo un kit que he pedido para hacer uno, a ver si me llega y le hago unas fotos: http://www.fingertechrobotics.com/proddetail.php?prod=ft-kit-cobra-4wd-chassis " onclick="window.open(this.href);return false; , lo he pedido con motores 20:1 ya que los 50:1 me parecen que tienen demasiado par según unos primeros cálculos para 500 gr y lentos @ 6V.
El kit tiene muy buena pinta: 
Por si alguno estuviese, por ejemplo, pensando en presentarse a AESSBot (4-6 Mayo) lo mismo está a tiempo.
Saludos,
Sphinx.
El problema principal del PID es que no está pensado para señales digitales y menos con tan pocos bits de información; tened en cuenta que estáis usando sólo 3 o 4 bits de información por muestreo. Por lo tanto ocurren cosas como las que muestra JMN en los vídeos (el motivo que no veas la oscilación brusca en el morro en el primer video, es que la frecuencia de señal de entrada del robot es mayor y por lo tanto las oscilaciones bruscas las hace más rápido, en un sistema analógico no tendrías ese problema).
La solución es augmentar la resolución espacial de los sensores (por ejemplo con una cámara digital, o el sensor de un mouse optico).
Otra solución es linealizar la entrada antes de aplicar el PID, es decir, aplicamos un filtrado que linealize la señal:convierta los puntos en instantes determinados, en rectas (o curvas según el orden) entre esos puntos.
S2
Ranganok Schahzaman
PD: la señal del PID es la diferencia de velocidades por lo que si la aplicas directamente a las dos ruedas (una sumando y la otra restando) estás haciendo el doble de esa señal --> o se divide por 2 o se aplica a una sola de las ruedas.
Otra solución es linealizar la entrada antes de aplicar el PID, es decir, aplicamos un filtrado que linealize la señal:convierta los puntos en instantes determinados, en rectas (o curvas según el orden) entre esos puntos.
Esto no lo he entendido. Como se pasan puntos a rectas o curvas para eso aplicarlo inmediatamente después al pid? Puedes poner el código C, o simplemente la función matemática, para hacer eso a ver si así lo pillo y pruebo a ver si da algún resultado positivo?
Es que no me he explicado muy bien...
Cuando recibes la señal lo que tienes son valores discretos en tiempos discretos algo como la señal u(k) (la última):
si utilizas esta señal directamente es como si estuvieras utilizando u^(t) por lo que el error de cuantificación (el número de bits de información que usas) es muy importante.
Para reducir este error lo que tienes que hacer es augmentar el número de bits de información: o añades más sensores o interpolas la señal (es como si conectaras los puntos de la señal u(k) con rectas). La forma de hacer esto es realizar un filtro paso bajo a la señal u(k) y hacer trabajar el PID con la salida del filtro a una mayor velocidad de la que muestreas la señal.
No se si se ha entendido ahora...
S2
Ranganok Schahzaman
El problema principal en el ajuste del regulador desde mi punto de vista sigue siendo la velocidad (ni nyquist, ni discretización, ni etc.., en digital o en analógico va a haber el mismo problema, con cambiar las constantes en este caso se mejora el problema), ya que sin control sobre la velocidad y siendo una constante la salida depende de ella, para un mismo tiempo la variación de la salida será distinta para más o menos velocidad, el que quiera que lo vea.
La discretización del error también es otro problema (mucho menor), como se dice para "solucionarlo" se puede implementar un filtro fir paso bajo, un ejemplo fácil de la función que pides:
error = (a*error(k-1) + b+error(k) + c*error(k+1))/3
Es decir tomar varias medidas presentes y pasadas para calcular el error. Hay que determinar el número de muestras a tomar para el cálculo del error, y el peso en el resultado final de cada una de ellas. Cuantas más muestras más valores toma la variable error, pero mayor es el retardo de la medida de la señal que se entrega al regulador, por lo que tienes más valores a cambio de un retardo en la señal de error.
Yo desde mi experiencia con los velocistas simples que llevamos te recomiendo que pruebes a ajustar las constantes en función de la velocidad, que es lo que te va a dar resultado y es fácil de hacer.
Por otro lado el ajuste de las constantes no sólo depende de la velocidad, si no también de la orientación del robot sobre la línea que influye en la variación del error para una determinada velocidad de giro, pero esto ya es otro tema distinto.
Es que no me he explicado muy bien...
Cuando recibes la señal lo que tienes son valores discretos en tiempos discretos algo como la señal u(k) (la última):
Tendrás valores en un tiempo discreto, pero no valores discretos... a menos que leas el sensor sólo con 1 ó 0, lo cual entiendo (desde mi no experiencia) que no se hace ❓
En cuanto al PID y las constantes... se podría buscar una constante que varíe con la velocidad medida del coche, cuanto más rápido la constante sube, y a la inversa. Así se tendría una gama completa de constantes, y no unos para rápido, y otros para lento... pero claro, habría que buscar a mano dicha constante (o mini-función), lo cual sería más engorroso que difícil.
Habría que buscar las mejores constantes a velocidad 10% del coche, a 20% a 30%... eso se plasma en una excel y se busca la fórmula que una los diferentes valores de cada constante. Con suerte será algo lineal, y sino, algo de segundo orden se aproximará mucho. Vamos, eso creo yo :geek:
