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
Si tienes un osciloscopio, no necesitas un generador de mucha precisión. Basta con que lo pongas a 10KHz o similar, y te centres en los flancos de subida/bajada con el osciloscopio. Con eso puedes medir todo lo que quieras.
Eso haría que con un simple NE555 fueses tirando, sin código ni nada.
El tiempo de propagación, que muy bien has nombrado, es fundamental para según que medición, y habría que medirlo con diferentes condiciones, especialmente la resistencia de carga del fototransistor, además de la variación en función de la distancia al objeto reflejante y la intensidad lumínica exterior.
Cuanto más me lo miro, más claro veo el que se debe usar un comparador analógico.
Por otro lado, 10m/s son 10 mm/ms, es decir, 10 micras por microsegundo. 20us equivalen a 0.2mm. Creo que eso es exagerar la resolución, ya que el tiempo de respuesta de los servos de la dirección, de los motores, de la plataforma mecánica para girar, etc, es mucho más lento (decenas de milisegundos, seguramente).
Mira que pensaba en hacer la adquisición seriando los sensores (es decir, mirando de uno en uno). Con eso te lo digo todo...
Juanjo, un poco si que me lo tomo a mal, si lo que quieres decir es que con mi anterior comentario jocoso se desvirtua el valor de post. Reconozco que no aportaba nada digno de ser leído, simplemente me hizo gracia lo del foco incandezcente, pues había dado por supuesto que JM ya sabía eso. Ahora, lo del Carrefour y Leroy&Merlin, ojalá hubiera por aquí alguno. En Ibiza no tenemos la suerte de contar con mucha variedad a la hora de ir de compras, ya sea de muebles, alimentación, electrónica, electrodomésticos, ... Es lo malo que tiene vivir en un sitio rodeados de mar.
Volviendo a temas interesantes, el problema que le veo a éstos sensores tan pequeños es que, mirando los datasheets, la distáncia de lectura suele ser de 1 mm o incluso menos. Por eso me pareció importante saber que tal le habían funcionado a JM, para saber si son prácticos o son demasiado pequeños.
Respecto a la distáncia de los sensores al robot, soy partidario de cuanto más lejos mejor así nos anticipamos. El máximo? no lo se, habría que hacer muchas pruebas.
Mejor sniffer o diferencial? Yo voy a probar con el diferencial. Ahora, los mexicanos usan el modelo sniffer y no les funciona nada mal, alguno ha visto los videos? Este año han corrido con radios de 12 cm !! Los nuestros en la cosmobot eran más del doble.
La idea de seguir las dos lineas a la vez, quien sabe..., ya nos la comentó Julio Pastor en la campus del año pasado, ahora tiene el inconveniente de necesitar muchos más sensores.
Estoy de acuerdo con beamspot que por mucho que corran los motores, si la mecánica no está a la altura no hay nada que hacer. Uno de los problemas de nuestro robot sniffer fué precisamente ese, tenía mucho rozamiento y no estaba bien ajustado mecánicamente.
Sobre el tiempo de propagación, no lo se, pero la luz infraroja viaja muy, muy rápida, por lo que no debería preocuparte (o a ver si es que yo no te he entendido).
Yo creo que hay dos cosas principales de las que preocuparse, como le afecta la luz ambiente, más de uno se ha ido de un concurso por esto, y nos podemos encontrar desde sitios oscuros, sitios al aire libre hasta con focos enchufados a la pista. Por eso muchos hacen lectura analógica, activan los sensores de uno en uno, para compensar este punto.
Y la otra es a que distancia debe estar el sensor de la línea, si nos encotramos con un sensor que sólo tiene 1 mm de margen, es decir que tiene que estar entre 1mm y 2 mm para poder hacer una lectura, pues podemos pasarlo mal a la hora de situarlo en el coche y de que este se mueva.
Lo del flexo me refería a que con poca luz lo activaba, por lo que un foco orientado al suelo le podría afectar. Por eso quizás sea mejor hacer fondo negro sobre línea blanca que al revés. De todas formas tengo que probar bien los 3 sensores que tengo.
Lo de los tiempos el sistema es mucho más lento, por ejemplo con un servo vas a tener 0.1s para poder posicionar 60 grados. La línea tiene un ancho de 2 cm, a las velocidades que vamos yo creo que no va a influir, (yo diseño para 2 m/s).
Sería interesante defenir el tipo de pruebas a hacer y como hacerlas, así todos podríamos realizar las mismas pruebas sobre distintos sensores y comparar los resultados.
Precisamente la idea de irlos activando en serie era la que yo tenía. Usar un serie paralelo para seleccionar sólo uno de los led's emisores, tener todos los colectores del fototransistor en paralelo, conectados a la misma resistencia, y esto a la entrada del comparador interno del ATmega (o lo que sea), con la otra entrada situada a una tensión programable (yo pensaba hacerlo con un PWM como DAC). Así tendría más juego y control sobre el nivel de detección. El código para hacer esto podría ser simple.
Tengo una placa diseñada (uff, estoy diseñando un monton, y la de la entrenadora AVR de colaboración con el maestro Ranganok necesita su tiempo) con este fin. Sería interesante probarla (cuando la pueda hacer, y cuando pueda disponer de los optos de Fairchild) para ver el resultado y la variación de la sensibilidad respecto de la altura, la iluminación ambiente, etc.
Por eso, yo propongo una tabla de pruebas: en un lado, diferentes alturas. En el otro, diferentes intensidades de iluminación, a oscuras, con un flexo sobre la pista (cerca), iluminación abundante de fluorescentes, e iluminación del exterior. Aprovechemos el sol que luce en estos lares. Incluso sería interesante repetir las pruebas sobre diferentes tipos de superficies, aunque esto es menos importante e influyente.
La idea de tener dos juegos de sensores (para detectar las dos líneas) no es mala en absoluto, y sería interesante elaborarla un poco más. Sería bueno ir haciendo una lista de ideas de cómo encarar el tema de la doble fila de sensores, y quizás elaborar un poco más las posibles estrategias a la hora de controlar este tema.
Y los tiempos del sistema no se limitan al servo (que es fácil de determinar), si no al tiempo de respuesta del vehículo en cuestion. Por ejemplo, un diferencial puede girar más rápido y en un radio menor, pero la aceleración angular no tiene por que ser tan buena como en uno tipo sniffer. Sin embargo, en este, la aceleración angular depende directamente de la aceleración lineal. Y esta última, depende de muchas condiciones. O sea, nada fácil.
A todo esto, sería interesante que algún profesor de teoría de servosistemas expusiese algún algoritmo chulo basado en esas teorías tan teóricas que explican en clase. No se, algo tipo Kalamar (Filtros de Kalman, extendidos o no), Dead beat, H2, H-infinito, Slipe&Sliding, etc). A ver si se pueden aplicar y sacar algo en claro.
Volviendo al tiempo de propagación (que también creo que es la nomenclatura correcta), no es el de la propagación de la luz, no. Se trata de que al activar un LED, hay que empezar a mover los electrones y los huecos en el cristal, para que estos se recombinen y empiezen a emitir luz. Por lo que hay un tiempo entre que se aplica tensión (que tampoco sube inmediatamente) y sale la luz. Típicamente nanosegundos.
Pero lo peor, es que la luz (mucho más debil, pues sólo es un reflejo) que incide sobre unión base-emisor del foto transistor, va acumulando electrones a medida que le van llegando los fotones. Esto implica que tarda un tiempo en formarse la corriente de base que lo activa. Entonces, resulta que la unión colector-base es un pequeño condensador que debe cargarse a través de una resistencia (la resistencia de carga), mediante una corriente que se va creando en el transistor. Eso implica que la resistencia de carga, la intensidad del reflejo, y la capacidad interna del transistor, van a influir en el tiempo en que este tardará en llegar a determinado nivel (es decir, entrará en 'conducción'). Por eso, una resistencia de carga grande, tarda más en cargar las capacidades internas, y aún más en descargarlas, que una resistencia pequeña.
Sin embargo, la resistencia grande hace variar mucho más la tensión que la resistencia pequeña. Así que se debe llegar a un compromiso.
Dado que la luz incidente sobre el fototransistor depende tanto de la reflejada como de la incidente del ambiente, resulta que tenemos un nivel de tensión a la salida que depende de ambos factores. Interesa que la luz incidente afecte mucho menos que la reflejada, y para eso hay varias técnicas: una es aumentar la luz reflejada a base de aumentar la luz emitida (resistencia del led emisor más baja), otra es acercarlo más a la superficie reflejante, y otra es reducir la entrada de luz ambiental por otros métodos, como por ejemplo, ponerlo debajo del vehículo.
Per cert, dragonet80, es molt agradable trobar un altre illenc per aquí. Un manacorí.
Lo del PID, por el código que he escrito una vez (para otro tema muy diferente), resulta que es relativamente sencillo de hacer. Lo malo, jodido, difícil, complicado y muuuy largo (que me corrija el maestro _Silent) es quitarle el Tocino. Es decir, sintonizar o ajustar los tres valores de ganancia P, Ki y Kd.
Homnre... maestro lo que se dice maestro.... más quisiera yo! xDDD.
Exacto! El PID son 5 o 6 lineas de C (en ensamblador que alguna más claro). Ajustar las constantes tp es dificil, es muy cansado por la de veces que hay que probar y volver a probar hasta que consigues la P. las otras dos las calculas por el 2º método de Zieguer-Nichols (el empírico con planta desconocida, que aunque yo lo estudié para sistema contínuos, creo que es básicamente igual para discretos). No hace falta ni saber regulación ni na para hacerlo. Solo hay que tener un poco de cuidado con el tiempo de muestreo de los sensores, puesto que afecta al sistema. Bueno, que conste que yo todavía no he hecho más que escribir el código y probar que el robot no se estampa, pero no he ajustado nada todavía, lo haré este finde y lo mismo me sorprendo.
En otro orden de cosas (me encanta esta expresión, le da al que habla y a lo que dice como categoría y relevancia, xDDD) la luz externa al sensor es un problema que lleva muchos años resuelto, un filtro. No se si es a lo que se refieren en post anteriores, que no es que no me los haya leido, esque no los he entendido :-S.
De hecho cualquier fotocélula funciona de esa forma. Es tan sencillo como no mandar al diodo una señal contínua si no una con una cierta frecuencia y luego filtrar la señal recogida del fototransistor y eliminar todo lo que no esté a nuestra frecuencia. TACHAN! ya nos hemos quitado los focos, el sol (este solo si no satura el sensoor por completo, en cullo caso leeremos una constante y no podremos ahcer nada) y todas las demás perturbaciones de luz y con un método muy muy antiguo.
No se si la gente que usa los sensores de forma analógica, lo hará porque hace esto de filtrar la señal antes de leerla o simplemente para calibrar.
Los circuitos para hacer estos filtros son relativamente sencillos de hacer analógicamente y están muy estandarizados. Me refiero a hacerlos por hardware vaya. Así nos quitaríamos todo el rollo ese de tiempos de adquisición y retardos de programación.
Lo malo es que habría que hacer un filtro por sensor, lo cual no se si es muy práctico o multiplexar, lo cual... bueno, directamente no xDDD.
Bueno, bien pensado si tenemos, por ejemplo 16 sensores, no parece muy buena idea 16 filtros en paralelo, tal vez si que habría que medir y filtrar por software.
Qué pensais? No se, igual estoy diciendo tonterías, como hago a menudo :-/.