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
Multibyte lo digo por tener varios bloques de 8 sensores, es decir tantos bloques como bytes.
Con un solo byte, calcular el error es tan simple como hacer una tabla de 256 valores. Con el multibyte no es tan fácil, y entonces hace falta una rutinilla.
El ATmega64, que fue el que usé en mi primer proyecto que salió al mercado con un micro, y por tanto, le tengo un cariño especial, tiene algo más que el simplemente cuatro veces más de memoria (RAM, Flash y EEPROM). Concretamente, tiene dos puertos serie, un SPI, un TWI (I2C), dos timers de 16 bits (genial para servos o para motores, con tres PWM cada uno), dos timers de 8 bits, capacidad para memoria externa, y hasta 16MIPS a 16MHz. Y bastantes interrupciones externas.
Eso de los MIPS es relativo, ya que no todas las instrucciones van a ser de un ciclo por reloj. Un valor más real sería 8 a 10 MIPS, según los saltos/llamadas/bifurcaciones que tengas.
Me parece correcto lo que propones con las resistencias del diodo y del transistor. Sería interesante mirar las características del comparador interno del ATmega para ver si se puede usar con éxito par hacer este tipo de lecturas. De esta manera, a partir del esquema que postee hace algunos días, con ligeras modificaciones, se podría tener una lectura serie con una cierta velocidad, a la vez que se calcula el error, todo en una misma rutina pequeña. Habrá que darle más vueltas al tema.
Bueno pues el puente en H hay que meterlo para poder frenar.
Lo del diodo queda claro, y los tiempos son similares a los que yo tb medí.
La rutina para el error yo pensaba utilizar algo similar a esto. Multiplicar por dos para evitar la coma flotante y trabajar con enteros.
Cómo se llevan los micros de 8 bits en c con la coma flotante? importa o da totalmente igual?
Lo que si hay que tener cuidado es en trabajar con tipos de datos iguales.
Voy a empezar ya a diseñar las placas con los diodos (que más o menos sé como las quiero para el miniz) en serie como dices, porque esto tiene tantas cosas que analizar que se puede hacer muy largo.
Lo de las posibilidades con tanto sensor no debe preocuparos. Si os fijais en el algoritmo de ablana en la página de JotaEme, se leen las combimaciones que interesan y las que no se desprecian, así te evitas el manejo de tanta combinación. En caso de haber una combinación no deseada, como se asigna el último error y se asume que no pasa nada por perder algunas lecturas puntuales.
Quiero ver esos videos del miniz a 1.6-1.7 m/s de media.... para cuando los vas a subir?
Yo diría que los micros de 8 bits no se llevan muy bien con las operaciones en coma flotante, quizá te saldría más a cuenta usar un factor de escala y trabajar con enteros.
