Taller Robotica

TRM – ETSEBOT’12

¡¡Hoy ha sido la ETSEBOT 2012!!

Como el año pasado (este más por las pocas veces que he podido subir a Tarragona), me encargue de diseñar y construir el robot que nuestro equipo, The Bot Team, utilizaría para la edición de este año.  Más adelante escribiré un artículo explicando el desarrollo del diseño y el montaje, fotos incluidas, pero ahora solo comento como ha ido el concurso.

Cabe destacar que este año el taller de robótica comenzó más tarde y eso ha hecho que hubiera menos equipos.  De hecho, robots diseñados por los estudiantes que han cursado el taller este año solo he visto uno, y no ha funcionado.  Se notaba que no han tenido tiempo de preparación para el concurso.  Nosotros hemos tenido problemas por parte del código.  Si bien este año el robot parecía mucho más estable a nivel mecánico, es en la parte de programación donde hemos tenido problemas.  Mis compañeros hicieron bastante compilando un buen programa, pero parecía no funcionar correctamente, pero no por culpa del programa, sino porque los pics son bastante delicados.  Ni aun programandolo en C hemos podido sacar un programa estable.  De hecho ayer la decisión tomada era la de no participar en el concurso puesto que no funcionaba bien el robot.  Pero ayer por la noche decidí «volcar la mesa» y cambiar unas cuantas cosas del robot, a nivel de control, y gracias a ella hemos podido participar en el concurso.

Pese a ello han aparecido problemas mecánicos.  El motor de tracción consumía mucha intensidad, lo que ocasionaba que no nos funcionara con las baterías y después resultó que el motor de tracción que escogí, junto con el sistema de transmisión, no nos daba el suficiente par para mover el coche.  Con lo cual este año tampoco nos ha ido bien.  El robot seguía bien la linea, tenía un buen código de control, pero como el motor no tenía par pues no se movía o lo hacía con muchísima dificultad.  Realizando unos ajustes de ultimisima hora, hemos podido participar en el concurso y, debido a la poca participación, incluso nos hemos clasificado para la ronda final.

De todas formas me voy satisfecho este año.  No ha funcionado bien, pero quizás, el tener pocas expectativas (dado los problemas de estas dos semanas) quizás ha hecho que la experiencia haya sido más divertida que la del año pasado.  Aun así, al igual que el año pasado, he aprendido mucho diseñando y fabricando el robot.  Además diseñé el robot para que fuera el fundamento de las próximas versiones, con lo cual sobre la base diseñada este año, vamos a ir modificando o eliminando lo necesario hasta conseguir un robot fiable.  Sí, vamos a seguir con la misma filosofía de robot (no sabeis muy bien cual, puesto que no hablé de Bendito v1.0, culpa mia xD) hasta que consigamos un robot que nos permita competir por las primeras posiciones en la final de la ETSEBOT.

Tengo pendiente una entrada sobre la potencia en un diseño de robot sigue lineas, y además otra en la que muestre un poco el robot del año pasado.  Añado otra entrada a la lista, la presentación de Bendito v2.0 :).  Próximamente me pondré a ello.

Os dejo con una imagen de como es el nuevo circuito para la ETSEBOT, cuyo record se ha establecido hoy, con un tiempo de 11,8 segundos.  ¡A batirlo!

¡Saludos!

Imagen
Nuevo circuito ETSEBOT, diseñado por URBots

TRM – Fase inicial de diseño – Control

Pese a que el concurso ya terminó, voy a seguir hablando un poco del proceso que llevamos para la construcción del robot.  Hablaré ahora de la segunda «etapa» en la que podríamos separar el robot.

  • Control

Esta etapa es la que se encarga de procesar los datos que se obtienen de los sensores infrarrojos y de emitir unas señales de salida que irán a parar a la siguiente etapa del robot, la de potencia.  ¿Qué usamos para recibir las señales de los sensores, procesarlas y emitir señales para activar otras partes del robot?  Hay varias formas de hacerlo.  Una es electrónica pura y dura, diseñar el circuito con puertas lógicas, aunque con este acercamiento veríamos muy reducidas las posibilidades de reajustar el robot.  Por ello desde el taller se nos recomendó utilizar un microcontrolador PIC.

  • ¿Qué es un microcontrolador?

Todo el mundo sabe cómo es un ordenador.  Esa «caja gris» que tiene pantalla, teclado y ratón.  Con ella se realizan una gran cantidad tareas tanto seglares como lúdicas.  Sin embargo, la capacidad de procesado del ordenador, la parte que hace cálculos está en el interior de esa caja gris, siendo todo lo demás medios para comunicar esa CPU (Unidad central de procesamiento) con el mundo exterior.  Sin embargo en el mundo existen un sin fin de «ordenadores» que pasan desapercibidos para la mayoría de personas.  Dichos ordenadores se encuentran en todas partes, en todas: Tarjetas de crédito, automóviles, juguetes, teclados, televisores, baterías, etc…  Tan grande es el uso de los microcontroladores que, sin exagerar, puede que en tu propia casa tengas varias decenas de ellos, incluso cientos. Aquí podéis ver algunos de ellos:

 

  • ¿Cómo funciona un microcontrolador?

Podemos pensar en un microcontrolador como si fuera un cuerpo humano.  El cerebro es el que toma las decisiones, pero necesita tanto «entradas» (sentidos), para saber qué esta pasando alrededor, como «salidas» (p.ej: sistema locomotriz) para mandar hacer algo en el mundo exterior.  Pues los microcontroladores igual, se valen de entradas y salidas para saber que pasa en el mundo exterior, tomar una decisión, y actuar en consecuencia.   Aquí podemos poner el ejemplo del robot sigue-lineas:  El microcontrolador observa el estado de los sensores infrarrojos (entradas), decide qué tiene que hacer según esos datos, y mueve los motores (salidas) para que el robot gire y no se salga de la linea.

 

  • ¿Quién le dice qué ha de hacer?

Pues nosotros.  El usuario es el que le dice al microcontrolador qué tiene que hacer según sea el estado de sus entradas.  Eso lo hacemos programando el microcontrolador.  Con nuestro ordenador nosotros creamos un código o programa, que hará algo al grabar dicho código en la memoria del microcontrolador.   Sería algo como esto:

Si sensor derecho no ve linea
Gira a la izquierda
Si sensor izquierdo no ve linea
Gira a la derecha

Esto no es el código tal cual se le graba al microcontrolador, esto se llama pseudo-codigo y es una forma de describir con muy pocas palabras lo que hará el código, facilitando después la escritura del mismo.  Como veis le damos unas órdenes al microcontrolador, le estamos diciendo que vaya mirando el estado de los sensores, y cuando alguno de los sensores no vea la linea, pues que haga algo, que gire hacia el lado contrario, de esta forma (forma pobre xD) estaríamos manteniendo al robot en la linea.  Decir que el microcontrolador SIEMPRE  hará lo que le hayamos programado, NUNCA hará algo que no le hayamos programado.  Por lo tanto podemos decir que cuando nosotros grabamos un programa al microcontrolador que no hace lo que nosotros esperamos, en el 99% de los casos es que nosotros lo hemos programado mal, es triste, pero es así xD.

Cómo quizás podéis ver, los microcontroladores tienen una versatilidad enorme: Podemos hacer cualquier cosa con ellos.  Existen muchas gamas de microcontroladores, pero aún con las más bajas, la cantidad de aplicaciones a poder diseñar son innumerables.

Existen muchas empresas que fabriquen microcontroladores, y por supuesto todas se programan diferente entre sí.  Freescale, Atmel, Microchip, Texas Instruments, Intel, Zilog, etc..  Podríamos decir que los microcontroladores más extendidos hoy en día a nivel de usuario y hobbista son los PIC’s de Microchip y los AVR de Atmel, por su inclusión en la extendida plataforma Arduino.  Es por ello que desde el taller se nos recomendó el uso de los microcontroladores PIC, en concreto el modelo PIC16F876, un modelo bastante utilizado y que tiene una buena cantidad de periféricos a su disposición.  Es este:

 

PIC16F876
Esquema del 16F876

Esto es lo que tiene que ver con la parte de control.  Como no pretendo hablar en el blog de una gran cantidad de detalles técnicos, es por ello que las entradas no tendrán una gran carga de datos técnicos.  Si alguien quiere saber más al respecto de los microcontroladores, aquí dejo unos cuantos enlaces:

 

¡Saludos!

TRM – Murphy, ¿qué haríamos sin ti?

Hoy se ha celebrado por fin el concurso ETSEBOT’11, y la verdad, para que engañarnos, con una decepción total.  No por el evento, sino porque hoy, de nuevo, la ley de Murphy ha entrado en acción (gracias Murphy <3 ), aunque solo con nuestro robot xD.  El caso es que, como comenté, ayer todo iba bien, sin problema alguno.  Ya preveíamos que uno de los equipos contrincantes mejorarían sus tiempos, así que ya íbamos asumiendo que iban a ganar.  Pero no imaginábamos que hoy al probar nuestro robot en el lugar del concurso, nada funcionaba como ayer.

Primeramente, por unos añadidos que le hicimos en la zona sensora del robot, el coche se pasaba de la medida máxima, así que nos hemos vistos obligados a hacer unos recortes en los cartones que impedían la entrada de la luz exterior en la zona sensora.  Así que ahí ya hemos tenido que cambiar un aspecto importante del robot, aunque este creemos que no ha sido el problema.  El caso es que al conectar las pilas al robot, ya hemos visto que sus movimientos eran más lentos de lo normal, y eso pese a tener pilas nuevas.  Hemos probado un par de vueltas en el circuito y el robot era muy inestable, nada comparado con lo que hacía ayer.  Y de hecho las pilas nuevas nos han durado 3 vueltas, algo totalmente anormal, porque antes teníamos una autonomía de unos 30 minutos aproximadamente.

Con lo cual, a partir de este momento, en los preliminares, sin haber empezado el concurso, ya sabíamos que iba a ser un desastre total.  Lo peor era no saber el ¿Por que?.  Me he sentido Mourinho.  Aunque yo no creo que UNICEF tenga nada que ver en esto, estoy seguro de eso :).  No sabemos las causas de que nuestro robot, no haya sido capaz de seguir la linea, pero creemos que el servomotor que utilizabamos para modificar la dirección del robot, debía tener algún problema, y eso era lo que hacía que fuera más despacio de lo normal y que las baterías se descargaran a una velocidad pasmosa, ni la GameGear oiga.

Así que hemos dado dos vueltas, totalmente horrorosas, y hemos decidido que era momento de retirarse del concurso, lo cual implicaba no haber pasado ni la ronda clasificatoria.  La verdad es que, como he comentado, ha sido una decepción total, no porque no fuera el robot, sino porque siempre ha ido bien, excepto el día que tenía que hacerlo.  Será el directo, el factor competición, la luz del Sol, o vaya usted a saber qué, pero hoy nada funcionó :(.

A partir de aquí, decidimos disfrutar del concurso, el cual estuvo muy bien la verdad.  A las primeras de cambio claramente se vio quienes iban a ganar el concurso, porque la verdad al final ha acabado siendo un símil con la F1: uno corría y los demás seguían, pero ha sido todo muy entretenido.  Nos han dado un bocadillo y un refresco gratis (menos mal que han intervenido para que nos dieran bocatas de los buenos, porque según palabras textuales de uno de los profes «nos iban a dar bocadillos de los cutres» jajaj).

En fin, el año que viene más, por supuesto.  Ya tenemos una cantidad ingente de ideas nuevas sobre qué mejorar, cómo hacerlo, y que mejoras se le pueden poner al robot, tanto mecánica como electrónicamente.  Así que esto quiere decir que veremos en la ETSEBOT’12, claro está, con nuestra línea de diseño «sigue-lineas-aspirador», porque algun día lo conseguiremos :D

Próximamente escribiré una nueva entrada con algunas fotos del proceso constructivo (he documentado fotográficamente todo el mismo) y algún video de las pruebas que hicimos.  Claro está a partir de ahora y hasta Septiembre/Octubre/Noviembre, veremos qué mes, volveré a hablar de mi proyecto de final de carrera aparcado desde que nos pusimos en serio con el robot, el tema de los wiimotes.

¡Saludos!


TRM – Horas previas al gran día

Como dije, hoy jueves era el último día antes de la gran cita, la ETSEBOT.  Hoy hemos probado unos cuantos ajustes nuevos, variaciones de velocidad, tiempos de espera en el programa para intentar que el robot oscile menos en las rectas, añadir más resolución al servomotor, pero la verdad es que no todas han hecho lo que esperábamos.  De todas formas, hemos hecho ajustes en las velocidades, aumentando un poquito más las mismas tanto en recta como en curva, y hemos conseguido arañar otros 2 segundos al reloj, con lo cual, con el cronómetro nos hemos quedado alrededor de los 16 – 16,5 segundos.

Veremos mañana como va el asunto de la medición de tiempos; en teoría la pista los medirá automáticamente, con lo cuál será mucho más preciso que el cronómetro, así que veremos realmente en que tiempos nos situamos.

Mañana actualizaré después del concurso, a ver si tenemos suerte y ganamos alguna de las dos pruebas y nos llevamos alguno de los dos premios :)

¡Saludos!


TRM – Nuestro robot sigue-lineas

Después hablaré de nuevo del proyecto, pero ahora un poco de información sobre otra de las cosas en las que ando liado: El Taller de Robótica Móvil. Hace ya varios años que en la URV hacen un taller de robótica cuyo objetivo final es la construcción de un robot sigue-lineas. Se crean varios equipos, de 4 personas como máximo, que deberán diseñar, no en su totalidad, un robot seguidor de lineas para después ver cuál de los robots construidos es el más veloz de todos.

Pues nuestro equipo, llamado The Bot-Team :), está ya enfrascado en el diseño y construcción de nuestro robot sigue-lineas. De momento estamos soldando los componentes en las distintas placas del robot. También estamos ya pensando el diseño constructivo del robot. Quizás más adelante, si el horario acompaña, hable un poco más acerca del robot, pero de momento decir que lo principal es hacer que el robot acabe el circuito, aunque sea más lento que el caballo del malo jaja.

Ya iré comentando más cosas al respecto, de momento os dejo alguna foto de una de las placas, y enlaces donde podéis ver videos de la competición del 2009.

ETSEBOT en youtube

Video resumen Taller Robotica Movil

20110401-023800.jpg