Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Hola,
Como sabréis estamos intentando construir un velocista en ARDE Madrid. Seguro que habréis visto las fotos o videos del driver o de la estructura con la reductora para un motor económico.
Bien, pues como no todo siempre queda perfecto una de las reductoras tiene menor rendimiento que la otra y eso hace que para una de las ruedas con una tensión de 0.5 V en el motor hace girar la rueda y en el otro pues hace falta hasta 0.8 V (además un motor está alimentado digamos en "directa" y el otro en "inversa"). El driver que hemos realizado tiene para tomar medidas de la corriente que circula por el motor y la tensión aplicada en el motor en cada momento, también sería fácil tener una lectura de las vueltas que da la rueda. Creo que con estas entradas se podrá realizar el control.
Mi intención es realizar pruebas de velocidad en línea recta, pero sin colocar los sensores para detectar la línea. Sería interesante compensar los distintos rendimientos de las reductoras y hacer que el avance de ambas ruedas del robot sea el mismo, en este caso el robot irá en línea recta.
Controlando esto podremos realizar pruebas de velocidad para el robot.
Si alguien tiene información sobre fórmulas, página web donde este bien explicado el tema o algún pdf bastante completo sería de ayuda. Y ya se que en google se encuentra todo, pero es mejor ir a leer directamente al lugar adecuado y no estar recopilando poco a poco la información y mirando decenas de sitios.
Gracias.
Ranganok, en robótica, en informática y, en todo en general, el infinito NO existe. Por eso te dije que creo que hablamos de cosas diferentes. Tú hablas de teoría, yo hablo de práctica. Pero no solo tienes que reducir el tiempo de muestreo del sensor (todos los sensores tienen un tiempo de respuesta), también tendrías que reducir el tiempo de respuesta del motor. Por tanto, en la práctica, eso es imposible de conseguir.
Estoy de acuerdo contigo que en la teoría podría se podría, pero estás tú de acuerdo con que en la práctica no es posible conseguirlo?
dragonet80, no estoy hablando de ideales, estoy hablando de señales analógicas. Para que se entienda mejor voy a cambiar el ejemplo: - Un control de temperatura y un sensor de temperatura.
Imaginemos que el control de temperatura tiene una desajuste, el PID (analógico) con la señal continua del sensor de temperatura se puede ajustar para que no exista diferencia entre la señal de temperatura deseada y la obtenida (aunque el control caliente más de lo que se le pide). En este ejemplo, además, los tiempos de retardo son bastante grandes (del orden de minutos), por lo que símplemente necesitaríamos que el PID actuase cada pocos segundo (discreto), dado que el tiempo de respuesta es muy lento.
Volviendo otra vez al motor, si en vez de sensores discretos tuvieramos un sensor que nos diese una tensión analogica en función de la posición con respecto a la línea, no tendríamos oscilaciones ya que en régimen estacionario (una línea recta), el PID ya se encargaría de eliminar el error. Lo malo es que por un lado tenemos sensores discretos y por otro usamos un control digital (que introduce su propio error al discretizar las señales). Sin embargo sería distinto usar sensores y controles analógicos.
S2
Ranganok Schahzaman
El PID discreto es un caso particular del PID continuo, mas sencillo de implementar.
En continuo es:
y[n]= Kp . e[t] + Ki |e(t) dt + Kd d(e(t))/dt
Kp = Constante del control proporcional
Kd = Constante del control diferencial
Ki = Constante del control integral
e[t]= error (Lectura actual – lectura anterior)
y en discreto:
y[n]= Kp . e[n] + Ki . a[n] + Kd . (e[n-1] - e[n])
a[n] = S e[n]
e[n]= error (Valor actual – valor anterior)
e[n-1]= error del ciclo anterior
a[n]= suma algebraica de los errores, poner límite aquí para AntiWindUp
Este proceso ha de repetirse 'm' veces por segundo, lo que determina el tiempo de muestreo. 100 veces (un proceso cada 10ms) es aceptable. El problema es que hay que tener lecturas válidas para cada ejecución. Eso exige sensores de velocidad rápidos. Si se construyen con encoders incrementales haciendo lecturas cada x milisegundos han de ser de muchos pulsos...
Creo que tengo algo de código ya escrito, si lo necesitas puedo pegarlo aquí...
Buenas Heli,
Si quieres me lo puedes enviar por e-mail. O si te parece bien lo podemos ver para la próxima quedada.
Saludos.
Estoy de acuerdo con lo que dice Rangnarok, pero también con dragonet80. Por un lado, es verdad que mezclamos señales y que en el caso de una señal continua sería menos apreciable, pero seguiría estando ahí, principalmente por que aunque hables de una señal continua, existe un tiempo de respuesta de los sensores y de los motores, por lo que además de continua, estás asumiendo sensores y actuadores ideales (sin retrasos).
Por otro lado, estoy con dragonet en que lo mejor sería 3 PID, 2 para controlar la velocidad de los motores y otro para posicionarte sobre la linea. Al menos es como pienso hacerlo yo también hasta que encuentre una solución mejor.
Un saludo.
