Si además quieres enviarnos un Artículo para el Blog y redes sociales, pulsa el siguiente botón:
Hola pues me dispongo a desarrollar un velocista en un plazo de un año, es decir, para el próximo cosmobot si dios o la caixa quieren. Y me gustaría pedir consejo y escuchar opiniones sobre diferentes puntos.
La base va a ser un coche rc de escala 1/28, como el miniz del cosmobot, esta vez otro modelo de coche, al que he podido incorporar un microservo de 0.1 s 60 grados, para el giro.
Mi primera duda surge en que tipo de sensores para detectar la línea usar, o cuáles hay disponibles. Lo ideal es que cuanto más pequeños mejor, y probablemente haga lectura analógica sobre digital, ya veremos como afectan los cambios de luz.
Yo hasta ahora sólo conozco dos modelos de sensor, en CNY70 y el QRD1114 de fairchild que nunca he usado, en el cosmobot vi a gente que llevaba diversos tipos de sensores, algunos de ellos eran muy pequeños, a ver si alguien me puede indicar otro modelo de sensores distintos de los dos anteriores, o foto trt y foto diodo.
Segunda duda, es como colocar los sensores, mi idea inicial es volver a usar dos placas de sensores, una delante y otra detrás, la de detrás es muy útil para conocer la posición del robot respecto a la línea, para poder realizar cambios de carril y acelerar, cuando el robot está centrado.
En el cosmobot vi a un robot, este http://es.youtube.com/watch?v=IVLpgTclsrI que usaba esa técnica para seguir la línea, me comentaron que esta era la manera correcta de hacerlo, o como se debia hacer. Me gustaría saber que ventajas tiene de hacerlo de esta forma frente a la clásica placa de sensores fija en el coche. Supongo que de esta forma se podrá obtener un error mucho más exacto.
Y por último que microcontrolador usar, he estado leyendo y creo que la mejor elección para este tipo de proyecto es un DSP, además de un mayor número de MIPS llevas los multiplicadores por hard, bastante útil a la hora de realizar operaciones.
Las señales que habría que leer en principio serían los sensores y un encoder que lleve el coche, que aún no sé muy bien donde se lo voy a poder colocar, quizás en el piñon o en la corona, y luego por último leer la batería. Las salidas el motor y el servo.
Aunque con un micro de 8 bits bien programado se puede hacer todo esto y más, yo creo que es un buen proyecto para iniciarse con micros mayores (almenos para mi), aún no sé la cantidad de operaciones que habría que hacer por segundo, mi idea inicial siendo muy optimista, es alcanzar los 2 m/s de media.
Así que a ver si alguien me puede aconsejar un micro para empezar, de momento yo he pensado en el dsPIC del que ya tendría el programador, por lo que el coste sería cero. Pero puestos a aprender no sé si sería mejor irme al mayor fábricante, es decir texas instruments, lo que no sé es cuánto costaría un DSP de estos, y cuánto el material para el desarrollo. La idea es usar un micro smd frente a un kit, por razones de espacio.
Tb me estoy iniciando estos días con atmel, que supongo que tendrá su alternativa a usar.
Gracias. S2
subiendo!
Me da un error al subirlo, mañana lo subo desde la escuela que tengo mas ancho de banda de salida.
He hecho bastantes mates con los AVR e incluso ARM. Mi consejo es olvidarse de las comas flotantes.
Alguien ha medido que un AVR a 16 MHz puede hacer alrededor de 50000 flops (operaciones en coma flotante). Pero seguro que puede hacer muchas más en coma fija.
Dada mi experiencia, la coma fija (es decir, trabajar con enteros tal y como propone JM) es muy rápida y eficiente, eliminando matemática compleja. Aunque las librerías de C son prácticamente transparentes para la coma flotante, y están bién optimizadas, estas ocupan mucha memoria y tiempo de cálculo.
Mi mejor opción sería contar en que bit empieza la línea negra, y en cual acaba. Entones sumamos las dos cuentas, y ya tenemos la medida. A esta le quitamos la 'consigna', que sería el valor que debería tener en el sitio que queremos la línea (que no tiene porqué ser el centro). Por ejemplo, si tenemos centrado, tal y como pone JM, tenemos que la línea empieza en el 3 y acaba en el 4, de manera que tenemos el 7. O sea, 3.5 x 2, tal y como propone JM.
Si queremos que esté centrado, entonces ponemos la consigna como 7, y el PID se encarga del resto. El error será la lectura medida menos 7, y de ahí se saca el resto.
La ventaja de leer en serie, es que se está haciendo la cuenta de donde empieza y acaba la línea negra mientras se van leyendo los sensores. De esta manera, es todo mucho más eficiente.
Otra cosa que puede acelerar el proceso, es estimar dónde se encontrará la línea negra, y sólo empezar a leer los sensores que estén uno o dos sitios antes. Si tenemos 32, y la línea debe estar en el 12, empezamos a leer desde el 10, y una vez que detectamos que ya no hay más línea negra, acabamos de leer. Eso puede reducir el tiempo de lectura al tiempo de leer 8 o menos sensores, aunque tengamos 32 o 64.
JM, no te compliques con coma flotante, para el error hay una forma más rápida de hacerlo:
char e; // error
char s; // señal leída (en bits)
char d; // señal deseada (generalmente 00011000)
e = s-d;
S2
Ranganok Schahzaman
Buenas, muy muy interesante el post, lo habia dejado de leer hace tiempo, y esta mañna, me lo he leido todo.
Tengo unas dudas, cuando haceis el PID, o PD, o PI o lo que hagais, como modelais el sistema ? es decir, por ahi he leido que el sistema que tratais es la posicion de las linias, no es correcto? Si es así, como lo modelais? Esta es mi gran duda, no tengo ningun problema en hacer PID, o lo que sea, el problema es como modelar el sistema a controlar....
Cuando haceis el diseño, lo haceis directamente a ojimetro? usais Laplace, y lo pasais a Z y luego al micro, usais solo Z y luego a micro? Alguien tiene diseño hecho con el Simulink, es decir, rollo bloques? Si alguien lo tiene, estaria bien si lo podiera subir...
Ranganok, según mi entendimiento (uno de mis peores puntos), lo que entiendo que sugieres tiene un problema de ponderación, es decir, que una desplazamiento hacia un lado incrementa muy rápidamente el valor leido, mientras que hacia el otro, lo incrementa muy poco. Es decir, si pasamos de 00011000 (24) a 00001100 (12), el error que da es muy pequeño, mientras que si pasamos a 00110000 (48), el error es muy grande (potencias de 2).
Respecto del modelado, creo que yo lo haría a ojímetro. Y llevo gafas... 😆
