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.
Pues que los tres tienen muy buena pinta 🙂
No se, son muy diferentes entre si. Ahí tendrás que decidir de que tipo lo quieres implementar.
Hola, unas preguntas:
Ranganok
dragonet80 ya te había entendido, y es por lo que digo que el PID no es para señales discretas. Voy a poner tu ejemplo llevandolo al infinito:
El motor al estar desajustado hace que el robot gire, pero como al momento el PID se da cuenta corrige ese desajuste (gira en sentido contrario). Si el sensor es discreto no se dará cuenta hasta pasado un tiempo T, por lo que tendremos una oscilación, si hacemos que T tienda a 0 (señal analógica) la oscilación cada vez será menor hasta desaparecer (en analógico el giro de ajuste del PID compensa al giro de desajuste del la reductora).
S2
Ranganok Schahzaman
El PID se dará cuenta "al momento" de que el motor está desajustado, pero ahí tienes un motor con su tiempo de respuesta, una electrónica con sus tiempos de propagación y una inercia que hará que la respuesta no sea "al momento" por lo que no estarías en el caso anterior. En analógico tendrás tiempo menores que los digitales, pero quizás esos tiempos digitales sean lo suficientemente pequeños comparado con el tiempo de respuesta del sistema, por lo que poco ganas haciendolo en analógico.
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.
¿Cómo es ésto? si tenemos una línea recta y dos motores que giran a distinta velocidad cómo evita el PID la oscilación, el PID corrige la trayectoría y nos situa sobre la línea, en ese momento el error es cero ya que estamos centrados, el error derivativo es cero ya que nuestra posición no cambia en el caso que comenta, y el integral lo mismo. Por lo que metemos a los motores el valor deseado para esta situación de PWM 10 por poner un ejemplo, con el que uno gira a 90 r.p.m y el otro a 102 r.p.m, que hace que el robot gire y por muy rápido que nuestros sensores y regulador corrijan la trayectoría nuestro robot ya ha girado debido a las inercias y tiempo de respuestas de los motores, servomotor, que no son instántaneos. Puede explicar como dice evitar la oscilación del robot en este caso con un único regulador para la trayectoría cuando los dos motores giran a distinta velocidad para un mismo valor de pwm.
Lo que habrá que determinar es que magnitudes, tiempos nos valen y cuales se pueden despreciar, el analógico será mucho más rápido y preciso (pero también tendrá sus incrementos y tiempos).
Pregunta respecto al código escrito por Heli:
if (tmp2==0xC0) goto NOEncoderD; // imposible, son dos pulsos
if (tmp2==0x00) goto NOEncoderD; // no se ha movido
¿Usar goto en este tipo de lenguajes no es una mala práctica que se debe evitar a toda costa?
Juanjo
Veo que han elegido un motor "económico" para realizar el proyecto, ¿qué razones tienen para elegir este tipo de motor frente a otro de más calidad con encoder incluido?. ¿Van a fábricar muchas unidades del mismo robot?. ¿Cuál es el coste y horas de trabajo en realizar el tren de engranajes que he podido ver en alguna foto?
Pregunto todo ésto porque creo que el coste de usar ese motor para un velocista va a ser bastante mayor de los 2-3 euros que pueda costar el motor, sin contar la solución del encoder que aún hay que añadir. Por lo que irse a un motor más caro puede que sea la solución más acertada, ya que a no ser que vayamos a hacer varias unidades el precio de comprar suele ser más barato que el de hacer, además de asegurarnos una calidad difícil de alcanzar muchas veces.
¿Han estudiado cuál es el coste de un motor de calidad con encoder incluido para poder comparar, y cuál estiman que va a ser el coste total del conjunto con el motor económico una vez añadido el encoder?
Interesante proyecto 8) .
Efectivamente, esos GOTO son una aberración. Siempre recomiendo evitarlos porque son poco elegantes y foco de problemas...
Sin embargo, debido a la optimización de la rutina para mayor velocidad de ejecución, es una forma rápida de salir del punto en que se encuentra el programa. La otra solución es escribir la rutina en ensamblador...
Seguro que hay otra combinación de IF-ELSE-WHILE etc que genere el mismo código, pero yo compruebo el listado en ensamblador que genera el compilador para ver si es suficientemente rápido. Como cumple con mi objetivo se queda así.
Ya te arrepentirás a la hora de corregir fallos, jajajaja.
Dragonet, respecto a lo que he puesto sobre los encoders, la opción 3 solo la usaría para temas de medidas en el laboratorio y entre la opción 1 y 2 está el tema de implementarlo de cero o acoplar uno existente. El implementarlo de cero tiene que ser muy interesante, pero no se, puede ser que sea bastante complejo y te metas en un gran lio.
Spt, contesto a tus preguntas:
- Sí, es un motor de unos 3 €, creo que para realizar pruebas es idóneo.
- Para realizar pruebas. Pues que el motor con encoder incluido y reductora ya está construido y ese no es el fin que persigo. Creo que como lo estamos implementando es bastante educativo y por supuesto puedes construirte la reductora a medida, el motor que elijas y con el encoder que decidas.
- jejeje, ojala. No es el fin, pero si ese fuese el caso solo tienen que decirnos donde hay que firmar, 😀
- El desarrollarlo es alto (horas, supongo que dos ceros de euros), pero implementarlo una vez realizado el primero, creo que unos 5 minutos y en coste 10-20 €.
- NO hemos realizado ese estudio, pero un buen motor con enconder y reductora puede estar entre 60-100 €. Seguro que el coste va a ser menor, me refiero el coste de replicación. No me planteo comprar el motor como dices, puesto que entonces la mejor opción sería comprar un robot, para programarlo, no es lo que perseguimos o al menos lo que yo persigo.
Sinceramente me gusta desarrollarlo y construirlo pero si solo fuese para competir creo que no tendría tanto entusiasmo.
Espero haber contestado a tus preguntas, de lo contrario puedes volver a lanzar las que consideres oportunas.
Gracias y saludos.
PD: Actualmente somos 3-4 personas aportando ideas y realizando algunos trabajos (ARDE-Madrid), aunque no estamos muy focalizados a un único desarrollo.
