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
beamspot, tienes razón, si lo tratas como enteros y no como bits. Además, y se me acaba de ocurrir, puede servir para discriminar una dirección (no pisar la línea roja) es menos importante que el error sea hacia la derecha (que tenemos espacio) que hacia la izquierda (que nos saldríamos de la pista).
S2
Ranganok Schahzaman
Lo de leer el primero y el último yo tb creo que es la forma de hacerlo, es lo mismo de la hoja. Si vamos a leer el primero y el último se hacen múltiplos de dos y problema de como flotante resuelto.
Lo que dices Ranganok creo que no vale para hacer un regulador, los incrementos hacía un lado y hacía el otro no son iguales. Hacía la derecha tienes 15, hacía la izquierda 240 o los que sean. Para el error necesitamos distancias o incrementos reales proporcionales con la distancia. Además de que los dos sensores de un extremo vale más que el sensor del extremo sólo que corresponde a una lectura más lejana.
Lo de estimar que líneas hay que leer primero es interesante si vamos a hacerlo en serie.
El sistema es muy difícil de modelar y llevaría mucho trabajo. La forma de hacerlo es experimental. Para la entrada y salida del sistema se utiliza la posición de la línea deseada y la posición leída.
Aprovecho para poner aquí las fotos de otro post donde trata el tema y explica lo que preguntas, la última es el ajuste.
Si se puede hacer si sacamos el módulo y signo de la operación, o si lo tratamos como dos nibbles diferentes:
unsigned char mode // error (módulo)
unsigned char sgne // error (signo)
unsigned char dl // señal deseada (nibble bajo dl=00000001)
unsigned char dh // señal deseada (nibble alto dh=00000001)
unsigned char s // señal (el nibble bajo esta invertido, la señal centrada dará 00010001)
unsigned char sh,sl;
sh = (s >> 4) & 0x0F; //rotación sin carry
sl = s & 0x0F;
if(sl!=0)
mode = (dl - sl);
sgne = 0;
else
mode = (dh - sh) ;
sgne = 1;
Con lo cual, con un pequeño ajuste en el trazado de líneas puedes ahorrarte muchas instrucciones.
S2
Ranganok Schahzaman
Eso que propones es más interesante, ya que el error no es lineal con la distancia, y no veo la necesidad de que lo sea. De hecho, al montar más juntos los del centro que los de fuera, se esta haciendo esto exactamente, pero dando más peso a los de dentro (pues un bit significa un error menor), que a los de fuera (pue el cambio de un bit en realidad se corresponde a una distanica mayor).
beamspot, yo creo que el error no debe ser lineal, ya que en los extremos un error puede producir que se salga de línea. Así que debería corregir los errores extremos con mayor rapidez que los internos (que no afectan tanto).
S2
Ranganok Schahzaman
