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
Luison, puesto que tus opiniones son contrarios a las mías, trataré de convencerte a tí, a los que lean el post de mi opinion extendiendola un poco más. Para estas opiniones me baso en mi experencia, que no es mucha, por cierto.
Respecto a lo del estado anterior del coche, un PID ya contesta a tu petición, un PID hace precisamente eso, tener en cuenta el error ahora, el error antes y la velocidad con la que varía. Si es verdad qeu a veces es importante que el robot esté situado, si bien eso depende mucho del circuito en el que vaya a correr y de la estrategia que se quiera seguir. Por ejemplo, si uno teine un robot muy rápido y estable, no le interesa que sea un robot situado, solo que corra to lo que pueda, puestoq eu al situarlo se corre el riesgo de que se confunda en su situación y se pierda. Además, si el robot es muy rápido, un cambio de carril y una frenada excesiva, le pueden hacer perder más tiempo que el que ganará acelerando más en las rectas.
Si el robot es un poco más lento, o no gira bien, se le puede hacer un algoritmo de control un poco más complejo que lo convierta en un robot situado, con control de carril y de rectas, frenada y todo lo demás.Todo eso JotaEme fué capaz de implementarlo muy bien en el programa de VIT.
En otro orden de cosas, la placa de sensores, en el ancho, como ya he dicho, es ver el angulo de giro del robot y nunca hacerla más ancha de lo que gira el robot. Es decir, que el robot sea capaz de seguir una señal en el último sensor (y altamente recomendable que no solo la siga si no que sea capaz de centrarse en ella).
En la distancia respecto del eje de giro, cuanto más lejos mejor, eso es evidente. Cuanto antes detectes el error, más te anticipas a él y más tiempo tienes para corregirlo antes de llegar. Esta característica es común tanto para robots diferenciales, como para los de dirección tipo coche (que tiene un nombre que no recuerdo). Otros tipos de direcciones pues ya no me atrevo a asegurarlo, pero apostaría a que tb mejora cuanto más lejos. En contrapartida, alejar la placa de sensores hace que menos angulo de giro provoque una mayor variación de distancia en la placa de sensores, con lo cual le podemos dar mucha más resolución y exactitud.
EDITO y así te leo, lo nuevo 😀
En mi opinión, mientras más lejos la predicción de la pista mejor. Con el cálculo de velocidad y la memoria se puede tomar mejores decisiones en el control autónomo. Corregir con escaso tiempo de reacción es peor.
Por otro lado, el ideal es hacer una predicción de largo alcance sin necesidad de alargar la longitud del vehículo. La mejor técnica es el análisis de imágenes para interpretar la forma de la línea negra en una pista de fondo blanco. Los sensores de imagen son cada vez más pequeños y requieren de menos circuitería, el lente y una pequeña red neural son elementos clave.
Si se dispone de memoria suficiente y la pista es cíclica, en la segunda vuelta se conocerá con anticipación los momentos para pisar el acelerador aun más.
Vaya, la verdad es que soy totalmente noob en ésta especialidad, así que hay cosas que no entiendo, por otro lado, yo no voy a construir un velicista a día de hoy...
Como dije, cuanto más lejos más rápidamente verás una variación de la línea (lo expliqué, mal está claro, con lo del palo). También te digo, que si los pones cerca y más juntos, obtendrás el mismo resultado.
en cuanto a lo del ancho, tienes toda la razón, ahí no te discuto nada, es lo que pensaba.
En cuanto a lo del PID... no sé ni lo que es a pesar de que mucha gente lo ha mencionado. Yo no soy de la escuela de la programación clásica, y suelo hacer MI programación como me lo dicte (mente?, razón? pon la palabra que quieras), aunque parece que tu PID hace lo mismo que lo que yo pienso, aunque no sé si en todos los casos que menciono, no sólo necesitas al entrar en curva, sino al salir de ésta, o incluso en la propia recta... aunque si tu dices que PID lo hace, yo te creo, aunque entonces no entiendo porqué "sesean" los coches...
La parte de un coche situado y no situado, ahí me he perdido, pero no te molestes que como dije a día de hoy un velocista no en mis planes.
Dicho lo cual, simplemente dictamino, yo tengo CERO experiencia en ésto, tú parece que más que yo, así que seguro que tienes razón, eso sí, si alguna vez me meto a hacer un velocista ten 100% seguro que el SW será algo completamente distinto a lo visto hasta la fecha, no sí si peor o mejor, pero distinto seguro 😉
A alguno del foro ya le he contado mi programación con el basicx y sabe de lo que hablo 😛
No.
El PID lo "único" que hace es que el sistema responda más rápidamete ante las variaciones de la entrada, osea, de la linea.
Un robot situado es un robot que tiene programada cierta intelegencia artificial, que le permite saber donde está, saber que le rodea, es decir, una cierta consciencia del espacio en el que vive, no solo se limita a seguir un estímulo externo como haría uno no situado. Pero vamos, esto de situado no situado no se si es una deficinicion formal o no, yo lo leido por ahí y lo repito `porque me parece descriptivo y doy por hecho que se entiende, pero veo que no :-SS.
Si teines ocasión, echale un ojo al programa que Jota hizo para VIT. Verás que lleva implementadas todas esas cosas que tú sugieres hacer. Como lo harías tú, ya es otra cosa.
Chris, no te parece que te has pasado un poco poniendo visión artificial y una red neuronal a un velocista? Muchas veces la mejor solución no es más potencia. Muchas veces un ordenador lento no necesita más RAM si no mejores programas, es lo mismo. Siplemente mejor diseño, para seguir e incluso memorizar un circuito de un velocista, sin bifurcaciones ni nada, basta con un encodes y una fila de sensores. La resolución de ésta, ya es otra cosa. No se, mi opinión es esa, pero seguro que me equivoco.
