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
Jota, poner los mismos sensores delante que detrás, bajo mi punto de vista, no es simplificar el código, es todo lo contrario. No es lo mismo manejar 12 sensores que 24, a más sensores, más complicación. creo que con una placa de 8 como la que ya tenemos va muy pero que muy sobrado (yo pondría solo 4 o como mucho 6).
Por otro lado, bajo mi punto de vista (por supuesto esto solo son opiniones), es lo mismo poner sensores grandes (CNY70) más lejos que sensores más pequeños mas cerca (bueno, eso es un hecho, no una opinion). Otra cosa sería poner pequeños y lejos, que ya sería lo más. Los pequeños permiten medir incrementos menores, lo cual permite un ajuste mayor del PID por tener más resolución del error.
En lo de los dos sensores delanteros me habéis convencido. Si son para control de velocidad si los veo de mucha utilidad. Sobre todo por el detalle que si además controlas en qeu carril estas, es c******* saber por donde te viene la curva para dejar al coche irse y frenar menos o frenar en seco para que no se vaya nada. Por cierto, donde decimos frenar, probablemente estamos diciendo acelerar menos o dejar el motor libre (que por fuerza contraelectromotriz ya frenaría bastante). Lo digo por lo de los trompos. Está claro que frenar no vas a frenar y en caso de que lo hicieras, siempre puedes hacer un efecto ABS que no te bloquee las ruedas. Si tuviéramos un encoder en las ruedas (cosa que yo veo muy importante y a la que todavía estoy dando vueltas como hacerlo) se podría incluso hacer un control de frenada que impidiera el bloqueo de las mismas.
Voy a dejar de escribir estos pedazo de tochos infumables, que seguro que no me lee nadie. Desde luego yo si viera estos tochos y más sabiendo quien los escribe, no los leería xDDD.
Pa tocho, uno de mis sargentos de la mili...
Lo de frenar es factible con un puente en H o un transistor (mejor MosFet) más. Y la frenada de esta manera es ABS 'per se', ya que frena más cuanto más rápido va el motor, o sea, que a bajas velocidades no frena.
De todas maneras, un encoder en las ruedas es algo en lo que estuve trabajando, pero en un principio sólo para una plataforma diferencial que tengo, para controlar la dirección y velocidad por PID y conseguir de esta manera que siempre fuese recto.
Poner lo mismo en un robot velocista me parece complejo, pero también el primer punto para poder 'memorizar' el circuito.
Mi idea de manejar sensores, siempre y cuando están en la misma línea (es decir, delante o detrás), es que la serie me devuelve un número que es la posición de la línea respecto del extremo. Ese número será superior a un byte sólo si tenemos más de 256 sensores en la misma línea, y como que va a ser que no.
Por supuesto, tardará un tiempo mayor en leer y procesar 32 sensores que 8, pero si tenemos tiempo, entonces mejor para la resolución del PID (que no por otra cosa, ojo). Esto en teoría nos permitiría afinar el control.
Por cierto, muy chulo, el vídeo.
El número de sensores es una cuestión complicada, yo habia pensado meter mas sensores para tener una resolución mayor, pero los robots de los del instituto San Blas llevan 6 si no recuerdo mal y demostraron ser de los mejores en Cosmobot y acabo de ver que coparon los 3 primeros puestos en Hispabot...
Lo peor de todo es que despues te ves los videos de los de Upiita que van endiabladamente rápidos con curvas increiblemente cerradas y llevan solo dos sensores...
¿cuantos sensores montar?.... creo que me quedaré con los 8 que tengo ahora.
furri.
Cierto, los de upiita vuelan como condenados. Creo que el tema está en 2 partes fundamentales: la mecánica y la programación. Hay que trabajar mucho en estas 2 partes: construir un robot muy ligero y fiable y currarse muy bien el algoritmo de control.
A nosotros llevar más de 2 sensores delante, tan sólo nos sirve para hacer un control más suave del robot: si se va un sensor hacia la izquierda gira un poquito, si se van dos ya giras más, y con tres giras a tope... (por ejemplo).
Es una concepción muy diferente a la nuestra.
Yo de momento sigo con los morros anchos, más que nada, porque así también me servirá para el robotracker.
Cierto, se me fue la pelota, no me percate que todo era digital, xD
