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
El circuito no lo memorizamos, lo que hacíamos era acelerar cuando el robot estaba centrado y frenar (bajar el duty en nuestro caso) cuando no lo estaba, la velocidad se daba según la distnacia a la línea.
Esto lo probamos experimentalmente y los resultados eran mejores que llevando una velocidad constante.
De ahí tener que meter un puente en H, para acelerar en recta y en el momento que se descentre frenar y reducir la velocidad.
La gente los suele llevar con velocidad constate, yo creo que es una ventaja poder frenar, no sé es cuestión de probar.
Hombre, está por ver si lo de frenar es más eficiente o simplemente con bajar la velocidad vale, lo mismo no es interesante frenar, despues de todo.
El tema de acelerar en las rectas depende mas que nada de la mecánica y es complejo. Si haces el robot más corto, y le das al coche convergencia y caida, tomarás las curvas mucho más rápido (interesante :-D) pero por otro lado, en las rectas oscilarás y no podrás acelerar mucho (no interesante .-(). En cambio si lo haces más largo, y le quitas caída y convergencia, el problema se te invierte y lo que das mal son las curvas aunque seas muy estable en rectas.
Esto es jugar y hacer pruebas mecánicas, cronómetro en mano, para ver si es mejor frenar, no frenar, con caida, sin caida y todo eso.
Lo de muchos sensores no lo tengo yo muy claro. Tal vez para seguir la linea cuando la tienes en el centro y vas muy rápido, si interese una alta resolución para poder corregir con mucha precisión las oscilaciones y centrarte, pero para curvas cerradas, el problema no es tanto si giras más o giras menos si no la velocidad a la que giras (los servos más rápidos van a 0,1 seg/60º con lo que en reaccionar recorres mucha distancia (unos 10cm he calculado así por encima a 2 m/seg).
Tal vez fuera interesante lo que sugieren pro ahí arriba. Ana placa con digamos, 4 cm centrales plagados de sensores (tantos como quepan) y luego otros 2 o tres por cada lado ya mas separados para cuando vas muy pasao. incluso a esas velocidades, yo me atrevería a decir qeu con los 4 cm centrales de sensores, sigues la linea y cuando te sales de ellos, giras todo por el lado qeu hayas perdido. Luego los sensores "periféricos" servirían de detectores de reentrada en linea si la has perdido y gestión de carriles.
Lo que está claro es que con la mecánica que hemos propuesto aquí, los giros van a ser muy lentos y eso es un gran problema. Tal vez se pudiera hacer una tracción diferencial con esta estructura poniendo otro motor atrás para girar más. O si no algún sistema de freno que permita frenar una sola rueda sería buena solución.
El problema de los sensores, no es tanto el volumen de datos, si no el tener que convertir a un valor de 'error'. Es decir, ocho sensores, que se leen como ocho bits, sólo te dan tres bits de 'error'. Y el problema de leer más de 8 es la complicación (en ciclos de reloj, me refiero) de pasar de multibyte a un valor de error.
Sobretodo si se pone una 'consigna' variable, según para donde vaya el coche, derecha, recto, izquierda...
Una opción sería tener tres conjuntos de sensores, izquierda, centro y derecha, y usar sólo uno de los tres para hacer el ajuste, según se vaya.
Respecto de la mecánica, estoy de acuerdo en muchos puntos, pero por lo que he leído de otros sistemas, la tendencia es a hacer un sistema intrínsecamente inestable desde el punto de vista mecánico, y luego estabilizarlo con la electrónica. Un ejemplo claro es el Harrier.
Claro que la capacidad de computación y el sistema de control es como un poco diferente. A ver quien es el guapo que pone un filtro de Kalman a un velocista. Sobre todo con un micro de 8 bits.
No hace falta que todo lo haga un solo micro, es decir, podemos poner dos, uno que se dedique únicamente ha hacer los cálculos y el otro que se dedique a leer los sensores y mover los motores.
O también podemos irnos a un micro de 16 o 32 bits o directamente a un DSP.
S2
Ranganok Schahzaman
No veo que problema hay con bits y bytes, se pueden leer todos de uno en uno y ver cuales están activados para calcular el error.
Con 8 sensores en los que dos pueden estar activados 2 al mismo tiempo salen 14 combinaciones distintas. Lo que hay que ver si esta precisión es suficiente.
Lo de pasar más de 8 sensores a un valor de error no debería ser problema, ya que el tiempo de las operaciones es muy rápido respecto al coche, y más si lo hacemos en digital.
Si puedes explicar lo de multibyte a un valor de error, porque no sé por donde vas x_x.
Yo en un principio quería utilizar un DSP pero para 2 m/s yo creo que con la velocidad de un micro de 8 bits llega.
Estoy pensando en utilizar un ATmega64 (ya que tengo que pedilos smd) que si no me confundo es como el 16 con 4 veces más memoria?
