PFC – Ha llegado el dia
Se que hace muchos días que no escribo ninguna nueva entrada, y se que voy empezando temas y los dejo sin terminar jeje. Pero hoy casi cerrare uno de esos temas. Mi PFC.
La verdad es que ha sido un verano atareado, pero todo llega a su fin. Hoy, por fin, presento mi PFC en la URV. Ha costado, pero si todo sale bien, hoy será mi ultimo dia de carrera universitaria. Se ha hecho muy largo este proyecto, pero el resultado ha sido satisfactorio. Mas tarde explicare que tal ha ido la presentación y colgare unos enlaces para que quien lo quiera pueda leer la memoria del proyecto.
¡Un saludo!
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!
- Nuevo circuito ETSEBOT, diseñado por URBots
Proyecto electrónico – Escenario del programa «Atrapa un millón» #4
Continuo con las explicaciones de la parte de electrónica:
- Etapa de control
Como he comentado anteriormente utilizaré una placa Arduino UNO para dicho control. Esta placa, mediante la introducción de programa, sería la encargada de gestionar la apertura y el cierre de las puertas. Una vez que tenemos alimentados los servomotores, debemos controlar su posición, y de esto se encargará la placa Arduino. Pero debería existir algún tipo de entrada, botones o pulsadores, que permitieran a la persona que controlara la mesa decidir que puerta debería abrirse. Así que decidí diseñar un mando con cuatro botones. Los tres primeros servirían para abrir las tres puertas, y el último para hacer un reseteo de la mesa: todas las puertas volverían a la posición inicial. El esquema de un mando así es muy sencillo:
Proyecto electrónico – Escenario del programa «Atrapa un millón» #3
¡Seguimos con el invento!
Voy a hablar de la electrónica que he utilizado para el movimiento de las puertas. Tenía claro desde el principio que iba a utilizar la plataforma Arduino para controlar el invento. Es muy sencillo de utilizar, tiene librerías para controlar servomotores (lo cual me facilitaría la faena enormemente), se ven resultados de forma muy rápida y, además, tenía ganas de hacer algún proyecto un poco más importante que encender luces con Arduino xD (aunque en cuanto a programación, el proyecto no es gran cosa, luego vereis).
Hay dos etapas diferenciadas:
- Etapa de potencia
- Etapa de control
En esta entrada hablaré de la Etapa de potencia
Proyecto electrónico – Escenario del programa «Atrapa un millón» #2
¡Seguimos con el montaje!
Aunque antes, una mínima explicación de lo que es un servomotor… y digo mínima porque va a serlo. Simplemente es un motor de corriente continua unido a un conjunto de engranajes reductores y un circuito de control. Todo unido nos da un motor especial, que de forma nativa, tan solo puede girar entre dos posiciones máxima y minima, que suelen denominarse como 0º y 180º.
Lo bueno de este elemento es que, gracias al circuito de control, según la señal que le enviemos al motor, seremos capaces de hacerlo mover de 0º a 180º, o hacer que gire hasta detenerse en la posición o grados que nosotros queramos, y mantenerse ahí. Es muy útil para una gran cantidad de aplicaciones, sobre todo en robótica. No voy a dar muchas más explicaciones sobre este elemento, porque considero que con esto es suficiente para entender un poco para que sirve, no obstante, una imagen vale más que mil palabras, así que imagínate un video:). Dejo uno que es bastante explicativo, y un par de enlaces de wikipedia.
Proyecto electrónico – Escenario del programa «Atrapa un millón» #1
El aburrimiento no puede existir donde quiera que haya una reunión de buenos amigos.
François-René de Chateaubriand
Esta frase describe bien lo que queríamos conseguir en la boda de nuestro amigo David. Queríamos realizar una sorpresa que gustara a los novios y que divirtiera a los invitados por igual. Quedamos en una hamburguesería para, entre bocado y bocado, idear alguna sorpresa original y de calidad. No se exactamente como surgió la idea, pero llegó un momento en que teníamos claro qué íbamos a hacer: Haríamos una versión particular del concurso «Atrapa un millón», claro está, sin el millón. Cosas de la crisis.
Pues bien, cuando surgió la idea, en mi mente apareció la mesa real del programa, y pensé que en realidad fabricar esa mesa era sencillo. Para controlar la apertura y el cierre de las puertas de la mesa sería suficiente con unos servomotores bien colocados y con la suficiente fuerza. Además, llevar el control de dichos servos sería muy sencillo utilizando una placa Arduino Duemilanove o UNO. Todo lo demás sería «bricolaje». Así que dije: ¡Yo fabrico el escenario! Qué capacidad para buscarme trabajo tengo… aunque en realidad yo pensaba en lo divertido que iba a ser fabricar el artilugio :D. Así que ¡manos a la obra!
PFC – Soporte Wiimote #2
Después de unos cuantos días dándole vueltas al tema del soporte del wiimote, he llegado a varias conclusiones:
- Tal como los tenía planteados, me hubieran consumido mucho tiempo.
- Tenía bastantes problemas para medir los dos ángulos de inclinación que me interesaban saber del mando.
- Además, la idea era que el soporte estuviera colocado en el techo, pero techos hay de todos los tipos: falso techo, pladur o incluso puede no haber techo, o sea, que esté a muchos metros de altura.
Así que después de pensarlo bien, voy a cambiar el techo por el suelo. Con esto eliminaré todos los problemas que estaban surgiendo en el tema de la sujeción del soporte del wiimote al techo. Una vez que he hecho este cambio las posibilidades se multiplican, puesto que la gran mayoría de personas que han tenido que usar soportes para un wiimote lo han hecho desde el suelo y no desde el techo. He visto algunas personas que han utilizado un soporte para micrófono:
Yo tenía una pinza para micrófono igual que esta, y al usarla me he dado cuenta de que encaja perfectamente en las dos ranuras que hay a ambos lados del wiimote, con lo cual ofrece una muy buena sujeción. Ahora lo que me falta es conseguir cuatro trípodes para micrófonos, y modificarlos para que la parte telescópica del mismo alcance un poco más de altura y así poder llegar a una altura máxima de 2,5 o 3 metros.

Soporte para microfono
Después, con respecto al tema de la medición de los dos ángulos, he visto ahora mismo una fórmula en un documento que pulula por internet, en el que puedo hallar el ángulo que el wiimote forma con respecto al suelo. Con lo cual haré un pequeñito programa para que me indique dicho ángulo y que el usuario pueda utilizarlo en el momento de la colocación de los mandos en los soportes. Para el otro ángulo, el que forma con la horizontal (con la pared) habré de buscar otro método ya que ese ángulo no lo da directamente el wiimote.
Esto es todo lo nuevo acerca de los soportes de los mandos. Espero solucionar todo esto cuanto antes para empezar a hacer pruebas y mediciones y poder continuar también con la redacción de la memoria.
¡Saludos!
PFC – Soporte Wiimote
Bueno pues ya tengo diseñado el soporte que fabricaré para poder aguantar y dirigir los wiimotes en los ángulos correctos. Será más o menos así:
Tengo la intención de hacerlo de aluminio, de 1 o 2 mm de grosor, eso dependerá. Consta de 3 piezas, por así decirlo:
- La primera sería en la que va enfundado el wiimote. Esta pieza tendrá dos cilindros que saldrán hacia el exterior. Todavía está por ver cómo haré estas piezas cilíndricas, pero la idea es que sean lo más cilíndricas posibles para que se puedan unir bien con la 2ª pieza.
- La segunda pieza se une con la 1ª para que ambas giren sobre el eje de unión, que sería las dos piezas cilíndricas de la 1ª pieza. La parte trasera de esta pieza va abierta para permitir que el usuario pueda subir y bajar el wiimote. Todavía no está dibujado en las imágenes anteriores, pero en la parte posterior tengo la intención de poner varios topes en los que posar la parte trasera del wiimote, de forma y manera que cada uno de esos topes indiquen un ángulo de giro.
- La tercera pieza va unida a la 2ª y es la que unirá el wiimote con el techo. En la pate superior habrá un montaje con dos cilindros de nylon (esa es la intención). Dentro de esos cilindros va un cojinete pequeño para permitir que el conjunto gire sobre si mismo y así poder modificar el ángulo que forma el wiimote con la horizontal. Todavía está por ver como aguantaré todo el soporte al techo, pero tengo alguna idea al respecto.
Eso es todo con respecto al soporte. Supongo que aún perfilaré algún aspecto más del diseño, pero voy a intentar tener uno construido para dentro de 2 semanas máximo.
¡Saludos!
29/3/2012 – EDITADO:
Comentar que el diseño ha variado bastante, debido a varias causas. Las planchas de aluminio que tenía no dispone de las medidas suficientes, y tampoco he podido tener acceso a una herramienta que me permita doblar dichas planchas de forma adecuada. Por lo tanto he cambiado el diseño, aunque el concepto básico sigue igual. Estoy cerca de montar un soporte, en cuanto lo tenga pondré las fotos.
Saludos!
PFC – Recta final
¡Hola a todos! ¿Cuánto tiempo desde mi última entrada eh xD? Para vuestra información todavía sigo vivo. Se que me queda un post pendiente sobre el robot seguidor de lineas del año pasado, cumpliré con ella, aunque espero que no se me junte con las entradas que iré haciendo del robot de este año. Pero eso otro día.
Ahora comentar sobre mi PFC, el cual aún tengo que entregar. Estoy inmerso en la redacción de la memoria del mismo, llevo más de la mitad, y estoy a la espera de ir recibiendo las correcciones de mi director de PFC. La redacción marcha bien; lo que me preocupa más es el conjunto de pruebas que tengo que realizar. Tengo que hacer bastantes pruebas con cuatro wiimotes colocados en una habitación, para comprobar la calidad de mi programa de seguimiento, y para ello tengo que diseñar un soporte para los wiimotes. Este soporte tendrá que permitir al usuario girar el wimote tanto por el ángulo vertical como por el horizontal y es lo que me está llevando un tiempo.
Tengo una idea aproximada del soporte, pero tengo que hacer un diseño previo para ver si es viable. No solo tiene que girar, sino que tiene que tener algún tipo de marca o de escala que muestre los grados de giro para que el usuario pueda colocar el wiimote en la posición deseada.
En cuanto haya conseguido hacer uno pondré una foto y me lanzaré a hacer las pruebas que necesito.
¡A ver si acabo ya xD!
Saludoos.
PFC – Estado actual del proyecto
Ha pasado algún tiempo desde la última vez que hablé del proyecto. Han pasado varias cosas. La primera es que se ha vuelto a retrasar la entrega del proyecto. Resultó que la presentación de diciembre solo era para los que tenían el PFC como única asignatura, y ese no era mi caso. Por lo tanto nos vamos a la siguiente que es para mayo.
El programa está acabado, en cuanto al objetivo del proyecto: Puedo localizar un objeto infrarrojo en una sala mediante varios wiimotes. El programa está actualizado ahora ya para poder utilizar los datos adquiridos de hasta 7 wiimotes. Faltan algunos retoques en el programa, pero son de tipo estético. No pensaba añadir muchas más funcionalidades al programa si no es que veo que tengo tiempo suficiente para implementarlas. Pero la idea es no alargar más el asunto; el programa está bien como está.
Lo único que podría cambiar mi parecer al respecto sería que en el momento de hacer el conjunto de pruebas en distintas salas, con varios wiimotes, observara el el algoritmo que tengo para obtener las coordenadas del objeto no funciona bien bajo algunas condiciones, o tuviera que retocar alguna cosa del mismo. En ese caso si que modificaría lo necesario para poder hacer que el programa funcionara bien en salas de hasta un tamaño determinado.
Y con la memoria tengo que ponerme ya. YA xD. Ahora que he terminado con algún examen que tenía voy a ver si comienzo ya con ella y avanzo en mi proyecto.
Además he empezado varios proyectos electrónicos a los que voy dedicando algunas horas y de los que posiblemente hablaré aquí. Recuerdo además que tengo alguna entrada pendiente del tema del taller de robótica y del robot sigue lineas, también me pondré con ellas, como mínimo para acabar lo que comencé :).
Esto es todo amigos, un saludo.
PFC – It’s aliive!!!
… Sí, eso es, ¡ESTÁ VIVOOO! Esta semana he hecho unos cuantos cambios, gracias a los cuales hoy he podido hacer un gran avance. He traducido a código algunas de las cosas de las cuales hablé con mi tutor la semana pasada, muchas de las cuales tienen que ver con las pestañas que nos indican la información de cada wiimote, aquí está una captura del estado actual de las mismas:
El tema de la calibración ha cambiado sustancialmente. Hay 8 cajas de texto en las que hay que introducir las coordenadas de cada uno de los cuatro puntos de calibración. Dichas coordenadas son referentes a la habitación, en metros, y teniendo presente que el punto de origen (0,0) de la habitación es la esquina superior izquierda de la misma. En la siguiente imagen se puede ver un poco más claramente:
He hecho lo siguiente:
- He tomado las medidas de mi habitación, en metros
- He posicionado un wiimote a una altura y grados con respecto a la vertical y la horizontal determinados
- He colocado mi plantilla de calibración y he medido a que posición se encontraban cada uno de los cuatro puntos de calibración de la plantilla, obteniendo así cuatro pares de coordenadas, todas ellas en metros
De esta forma tengo las coordenadas absolutas de cada uno de los cinco elementos que hay arriba, de tal forma que, teniendo las coordenadas de los cuatro puntos de calibración (en metros) puedo ahora hacer un cambio de base directo entre las coordenadas del wiimote y las coordenadas absolutas de la habitación.
No se puede observar, pero cuando se rellenan todas las cajas de texto, aparece en medio de la plantilla en miniatura el botón «Calibrar», de forma y manera que solo cuando hemos rellenado todos los datos, aunque sea con ceros, sea posible la calibración.
También he añadido dos botones adicionales en la parte superior de la ventana. Sirven para cargar y guardar los datos de calibración del wiimote al que pertenece la pestaña en la que nos encontremos. Por el momento tengo montado el asunto de la siguiente forma:
- Cuando se han rellenado todos los datos y una vez que hemos pulsado el botón «Calibrar» y hemos terminado la calibración, pulsamos el botón «Guardar datos» y nos guardará un archivo que tendrá el siguiente nombre: «calibration_data_»número de wiimote».dat». De tal forma que si calibramos 4 wiimotes, habrá cuatro archivos.
- Si queremos cargar los datos de calibración que hayamos guardado, pulsamos el botón «Cargar datos» y nos cargará los datos de calibración del wiimote correspondiente a la pestaña activa. De tal forma que si las condiciones de la instalación no han variado, podemos usar los datos de calibración anteriores. (Esto lo he acabado de implementar después de haber estado media hora introduciendo los pares de coordenadas a mano @_@ )
De momento el tema del cargado y guardado de datos se queda así. Si veo que puedo hacerlo de otra forma, con un solo archivo, pues lo haré, pero no voy a perder demasiado tiempo en esto.
Una vez he hecho todos estos cambios y he corregido algunos errores, he podido observar como en efecto funciona, o sea, que, de momento, con un solo mando soy capaz de ver un objeto infrarrojo y además indicar la posición X e Y relativas a la habitación, o sea, casi casi el objetivo de mi proyecto. Como sabéis tengo un sistema de dibujado del área que teóricamente ve el wiimote, con colorines y tal: pues bien, he podido comprobar como en cuanto saco el objeto infrarrojo de esos límites, el mando no ve el objeto, lo que quiere decir que las medidas teóricas se corresponden casi al 100% con la realidad, algo que me es encanta, ya que quiere decir que el sistema de dibujado es fiel a la realidad y que por lo tanto es útil. (Me falta hacer el tema del redibujado de las áreas de visión una vez calibrado cada wiimote)
Con lo cual ahora lo que me falta es probar con dos wiimotes en posiciones distintas. Voy a probar a poner un wiimote más a la izquierda del que tengo colocado, y lo voy a colocar de tal forma que entre ambos wiimotes compartan una cuarta parte de su área de visión, y haré comprobaciones con la media de la coordenadas que entreguen ambos mandos. Dependiendo de como salga la prueba podré implementar un pequeño código que determine que coordenadas se utilizarán cuando me lleguen 7 pares de coordenadas, o sea, cuando el programa funcione a un 100% de capacidad.
Luego tan solo quedará trastear un poco con todo el programa para ver si encuentro algún que otro bug (ya he visto alguno ¬¬) y pasar a documentar bien las pruebas para poderlas usar en la memoria del proyecto y poder así entregar unos resultados definitivos de mi proyecto. Así que a ver como se me dan estás dos semanas :D
¡Saludos!
PFC – Resumen semana #9 + Bonus
Hola de nuevo!
Ayer me reuní de nuevo con mi tutor de PFC. Desde el verano (durante el desfallecimiento de nuestro robot sigue-lineas) no habíamos vuelto a coincidir, pese a que más o menos estaba enterado del estado del proyecto. Pues bien, pensaba que lo que había hecho hasta el momento no estuviera del todo bien, pero bueno al final resultó que hasta el momento le convence el estado del proyecto.
Hemos hablado de lo que falta por terminar del proyecto y de algún concepto que había que tener un poco más claro (si hubiera habido alguien contando palabras, hubiera llenado una hoja con la palabra «calibración» xD). En resumidas cuentas falta lo siguiente:
- Ser capaz de obtener las coordenadas del objeto que ve el wiimote, no relativas a la posición del wiimote, sino a la sala, algo que sobre el papel tengo más o menos planteado, pero que falta llevarlo a la práctica.
- Para realizar lo anterior hay que hacer algunos cambios en el método de la calibración de los mandos. Además creo que voy a dejar de usar la palabra calibración porque la comparación entre la palabra y lo que intentamos definir con la misma se asemeja a la de las churras y las merinas xD.
- También, aunque yo doy los datos de cómo estarán colocados los wiimotes, esto son datos teóricos, que puede que no sean 100% reales una vez que se hayan colocado los mandos. Por lo tanto una vez que estén los mandos colocados y se haga la transformación de coordenadas, se realizaría un re-dibujado de las áreas de visión de los wiimotes, habiendo entonces dos posibles representaciones: la teórica y la real.
- Comenzar a hacer ya la memoria. Plantear los capítulos que habrá que hacer y comenzar a hacerlos para poderlos revisar con tiempo.
- Currar, mucho xD, porque tengo dos meses y medio para acabar el proyecto.
- Varios retoques en el sistema de representación gráfica de los wiimotes. He añadido un poco de color al círculo que representa el wiimote para que, visualmente, se pueda saber que área de visión corresponde con qué wiimote.
- Corregir algunos bugs (errores) que surgían dadas según qué circunstancias cuando trabajas sobre el sistema de representación gráfica de los wiimotes.
- He añadido una pestaña nueva al programa en la cual, de un vistazo, se pueden ver todos los datos importantes de todos los wiimotes de un vistazo. Ya pondré alguna captura, pero no tiene mucho misterio.
- He añadido la posibilidad de guardar y cargar los datos que posibilitan la transformación de las coordenadas del wiimote (a.k.a. calibración), aunque solamente están hechas las funciones; hace falta implementarlas en el programa.
- También estoy añadiendo los menús del programa, quizás con opciones para cargar y guardar los datos de la transformación de coordenadas junto con alguna otra opción más.
PFC – Pantallazo de la semana #8
Hola!
Esta semana ya empieza el curso de nuevo, y… ¡¡se me olvidó matricularme de las asignaturas de la uni!! Yo no se que ha pasado esta vez, pero desde que llegó el mail de la matriculación de este año, allá por Julio (o Junio, ya no me acuerdo), no se me ha vuelto a pasar por la mente el hecho de que DEBO matricularme de las asignaturas. Así que después de pasar la fase ¡OMG, OMG, OMG!, pasé a tranquilizarme (no mucho) y a buscar los mensajes de la uni en el correo y ver la página web, a ver si había más fechas para matricular. Recordaba que sí, pero no estaba seguro.
Duré poco buscando en la página web, veía mucha letra y pocas nueces xD, los nervios debieron cegarme porque la página está bien hecha (contraejemplo: Renfe, para cuando queráis una tarde del terror entrad en su página web y buscad, lo que sea, buff que traumas comprando billetes :@). Así que llamé a la uni, y entre eso e ir recuperando la visión después del «kernel panic» inicial, ya vi que a partir de mañana (¿hoy xD?) hay otra periodo de matriculación, fiuf xD
Así que nada, peripecias de estudiante… trabajador claro, porque si no hubiera sido por estar ocupado este verano, pues me hubiera acordado de matricularme…. cof, bueno, pues eso, que a ver si consigo matricularme que aun no está todo dicho :p.
Y de paso, dejo una captura de pantalla de algunos avances que estoy haciendo con el proyecto. A finales de esta semana ya daré más detalles de las cosas que he añadido con respecto a la anterior actualización, y también sobre el estado del proyecto en general, ya que tengo que hablar con mi tutor de PFC que, por supuesto, estará leyendo esto :):
Y esto es todo, ¡saludos!
P.D: Por cierto, cuando estaba documentándome para comenzar el PFC, hace meses, encontré un proyecto de unos japoneses que habían conseguido hacer algo muy parecido a lo que pretendo conseguir con mi PFC. Pues resulta que en el PDF en el que explicaban muy brevemente el proyecto, tenían sus mails, así que pensando que igual podían resolverme algunas dudas decidí escribirles un mail. ¡¡Y uno de ellos ha respondido!!, eso si, con un inglés muy japonés, pero entendible al fin y al cabo. Así que igual con alguna explicación que pueda conseguir de ellos puede que resuelva algunas dudas que tengo sobre algunas cosas que me faltan por hacer. Además es majo el hombre, está contento de que le haga preguntas jeje.
PFC – Resumen semana #6 y #7
Bueno, ya han pasado otras dos semanas, pero estas han sido mejores que las dos anteriores. Por fin he conseguido calibrar los wiimotes. Después de dar muchísimas vueltas, de probar el código de la calibración de mil maneras y de compararlo con otros códigos… no llegué a una conclusión clara de por qué no me funcionaba bien :S.
Así que inicié una búsqueda por google sobre el tema de la calibración de los wiimotes, y todo el rato me encontraba el mismo código de calibración, el creado por johnny lee, por lo tanto seguía igual, ya que tanto el cálculo de los puntos de calibración, como la posterior transformación de las coordenadas del punto que ve el wiimote no me funcionaban, ya había perdido suficiente tiempo con esto. Buscaba pues una librería que se encargara únicamente de la calibración, y tuve la suerte de encontrar una. Esta librería se compone de 5 o 6 funciones que se encargan tan solo de recoger los puntos de calibración vistos por el wiimote y devolver las coordenadas transformadas.
Después de hacer unos retoques en el código para implementar esta librería, compilé, y probé el programa…
El punto rojo que se ve en la zona izquierda de la pantalla es el LED infrarrojo visto por el wiimote. En la zona superior derecha tenemos dos PictureBox. La primera dibuja el polígono formado por los cuatro puntos que ve el wiimote en el momento de la calibración. Y el segundo dibuja esos mismos puntos una vez han sido transformados.
Si os fijáis, en la imagen de la izquierda podemos ver como lo que ve el wiimote está «distorsionado» por lo que expliqué acerca de las perspectivas en la entrada anterior. Lo que en el mundo real es un rectángulo (formado por cuatro marcas dibujadas en una plantilla), el wiimote lo ve como un trapecio, algo que no nos es útil a la hora de determinar coordenadas. Sin embargo, en la imagen de la derecha, podemos observar esos mismos cuatro puntos, pero transformados, con lo cual estamos observando, ahora sí, un rectángulo.
He añadido una pequeña caja de selección, con el texto «Ver Calibrado». Si no pulso esa casilla, en la picturebox grande de la izquierda observo la coordenadas que recibe el wiimote, sin transformaciones, y por lo tanto distorsionada. Si la pulso entonces activo la transformación de las coordenadas que recibe el wiimote, y por lo tanto puedo verlas por pantalla. Hasta aquí todo bien, aunque tengo algunas dudas/problemas que tengo que resolver:
- Dimensiones de la plantilla
La plantilla que utilizo es así:
Son cuatro folios pegados con celo, con estas cuatro marcas. Las dos marcas del lado más largo están separadas 61 cm, y las dos marcas del lado más corto están separadas 34 cm. Pues bien, al programa hay que decirle cuál es el tamaño de la plantilla de calibración
Si la plantilla está dibujada en una pantalla de ordenador, la dimensiones de esta plantilla no se le da en cm, sino en píxeles. Por lo tanto en una configuración estándar las distancias que introduciríamos en el programa serían 1024 y 768. Yo he usado estos datos para mi calibración, porque todavía no se muy bien como darle al ordenador los valores del tamaño de mi plantilla.
- Area de calibración
En la primera imagen, en la que enseño parte del programa, podeis ver en las picturebox de la parte superior derecha, que el trapecio es más pequeño que el rectángulo transformado. Esto quiere decir que las nuevas coordenadas máximas pasan a ser las que yo le he dado por programa (1024 y 768) y por lo tanto si el wiimote ve un objeto infrarrojo, previamente se podía observar aunque saliera de la zona del trapecio, ya que todo el cuadrado es el área que ve el wiimote.
Sin embargo ahora cuando el objeto sale mucho de la zona del trapecio, en la picturebox de la derecha, en la de las coordenadas transformadas, ya no se verá el objeto. Si bien si seguiremos teniendo sus coordenadas, la verdad es que esto supone un problema. El wiimote sigue teniendo un gran rango de visión, pero el rango que yo puedo reflejar por pantalla será menor, y dependiendo de lo pequeña que se vea la plantilla de calibración, mucho menor.
Además, si suponemos que, como mínimo, dos wiimotes ven el mismo punto infrarrojo, cada uno entregará unas coordenadas relativas a su posición, y no a la absoluta de la habitación donde se encuentren situados los wiimotes y el objeto. Con lo cual habrá que convertir esas coordenadas; y si además las que recojo del wiimote pueden estar con números negativos, pues se complica más el asunto.
Así que veo una solución posible, un plan B: Que la plantilla de calibrado no exista. Esto quiere decir que, por ejemplo, imprimiría en una hoja en blanco una de esas marcas de calibración, pero una marca de calibración enorme. Movería el punto infrarrojo a lo largo de la habitación para obtener los 4 puntos de calibración, que serían los 4 puntos que me permitieran «dibujar» el rectángulo más grande posible:
Sería algo así. Tened en cuenta que la plantilla, es el suelo: marcaríamos los puntos con folios con esa señal, y después, en el momento de la calibración, pondríamos el punto infrarrojo encima de cada uno de esos puntos, tal y como si hiciéramos con la plantilla pequeña. De esta forma el área de visionado que tendríamos, aun después de transformar las coordenadas sería el máximo posible, y solo perderíamos un poco de área de visión que supliríamos con los rangos de visión de los demás wiimotes. Quizás se podrían mover un poco los cuatro puntos para que no utilizar los extremos del área de visionado del wiimote, de esta forma la posible pérdida de precisión cuando el objeto estuviera en dichas zonas sería menor.
Seguramente se me ocurrirá algún inconveniente más, pero vaya esto es todo por el momento. También comentar acerca del punto infrarrojo. Hasta ahora utilizaba uno de los montajes que hice, en concreto el primero que muestro ahí. Y para alimentar el montaje usaba la fuente de alimentación, con un cable que cruzaba toda la habitación, y con un interruptor en medio para poder hacer los destellos necesarios para el proceso de calibración. Uno al final se acostumbra, pero bueno decidí hacer un pequeño montaje para usar un apila de 9V y ahorrarme los cables (mi habitación parecía una jungla, ya lo parece, pero con tantas «lianas», aún mas :p ). Os enseño el montaje en fotos, y mañana o pasado pondré el esquema (muy simple):
Sí, es una caja de plástico que contenía cartas :p. La vi y supe que ahí iba a hacer mi montaje. Tan solo tengo una pila de 9V, un pulsador de tipo boton, y un doble conmutador. Cuando tengo que realizar la calibración, voy pulsando el botón de la parte superior para ir haciendo destellos infrarrojos en los puntos de calibración. Pero cuando necesito que le punto esté accionado durante un rato, pues todo el conmutador que se ve en el lateral del a caja de cartas, y de esta forma está encendido de forma permanente, o por lo menos hasta que se acabe la pila. La verdad es que es bastante más cómodo que lo anterior.
Y esto es todo por estas dos semanas. Ahora me voy a poner a ver el punto infrarrojo con dos wiimotes, y a transformar las coordenadas relativas de cada uno de ellos, a las coordenadas absolutas de la habitación. A ver cómo se me da eso ;).
¡Saludos!
PFC – Resumen semana #4 y #5
Como cuesta actualizar esto. Bueno hago un pequeño resumen de estas dos semanas. Estas dos semanas han estado llenas de problemas. Para empezar mi relación odio/odio con Windows. Después de solucionar este asunto, volví de nuevo a ponerme manos a la obra.
Estaba con el tema del dibujado del área de visión de cada wiimote, pero no acabé de solucionar este problema. El tema del dibujado es bastante problematico cuando tienes que dibujar capas. Dibujas todo, y luego cuando el usuario cambia algún dato como alguno de los ángulos o la altura del mando, tiene que volver a redibujarse en base a los nuevos datos de entrada, pero al mismo tiempo borrar lo que había antes. Y esto lo hacía bien, pero al cambiar luego el código para poder dibujar el área del wiimote diera igual el valor del ángulo alfa, me encontré con problemas que de momento no logré resolver.
Es por ello que decidí cambiar de tarea, lo he dejado aparcado para un tiempo más conveniente. Me puse directamente con el código de la calibración de los wiimotes. Para explicar esto de la calibración usaré una imagen que encontré en otro blog y me sirve para explicar brevemente el asunto.
El tema son las perspectivas. Si os fijáis, cuando el wiimote, en la mayoría de los casos, nunca verá de frente el área donde se encuentra nuestro objeto. De tal forma que siempre lo verá en perspectiva. Necesitamos crear un código, en el que marcamos cuatro puntos de calibración. De forma secuencial, iremos iluminando un led infrarrojo en cada uno de esos puntos de calibración para decirle al programa cuáles son los márgenes del área que queremos visionar. Una vez hecho esto, tenemos que tener presente que lo que ha visto el wiimote no es un cuadrado, tal y como nosotros le hemos marcado, sino un trapecio, por estar viendo todo en perspectiva.
Es por ello que hay que utilizar una serie de cálculos matemáticos para transformar la perspectiva de la imagen obtenida. Así obtenemos un cuadrado. Podemos decir que cada uno de los puntos que existen en el trapecio, tiene un equivalente en el cuadrado, asi que convirtiendo las coordenadas x e y del punto infrarrojo cada vez que el wiimote lo vea, estaremos corrigiendo el problema de la perspectiva. Esto se conoce como Homografía. Quizás con esta imagen se vea mejor.
Pues bien, estos cálculos ya están hechos en el código fuente que compartió Johnny Lee, por lo tanto solo hay que aplicarlos. El caso es que he tenido problemas, y no por los cálculos, sino por la versión del Visual Studio. Resulta que en la versión 2005 si accedes a un control desde un hilo distinto al que se creó todo funciona bien. En cambio en la versión 2008 pues el programa da error. Hasta que encontré que el fallo se debía a esto, pues tarde varios días, más de los que yo quería.
El caso es que ya lo he resuelto. Encontré dos formas de solucionarlo, una elegante y otra no. De momento uso la no elegante, más adelante ya veré como puedo implementar la forma elegante. Ahora seguiré con el tema del código de calibración y coordenadas. Claro el mando ve el objeto, y para ese objeto tiene unas coordenadas x e y. Pero dichas coordenadas son relativas al wiimote. Lo que tengo que hacer es transformar dicha coordenadas relativas a unas absolutas, que me indiquen las coordenadas x e y del objeto respecto de la sala y no del wiimote. A ver qué consigo :P
Saludos!
P.D: A ver si logro perder menos tiempos con estos problemas… y despertarme más temprano tambien xD
Un saludo al equipo de Microsoft
Eso es, quiero saludar a todo el equipo de desarrollo de las distintas versiones de Microsoft Windows, por hacer el peor sistema operativo que existe en el mundo. Sí, MS-DOS es mejor incluso (sí, MS-DOS es de Microsoft, pero lo compraron hecho, no lo desarrollaron ellos). De hecho, he llegado a la conclusión que ellos no utilizan su sistema operativo de forma diaría; deben usar otro, OS X, alguna distro Linux, o cualquier sistema operativo hecho por algún estudiante de informática. Es por estos momentos por los que recuerdo porqué di mi paso a mac, para pasar más tiempo usando el ordenador, y menos arreglándolo y perdiendo pelo.
Ayer el ordenador que uso para programar decidió que no era buen día para iniciar, que no tenía ganas. Claro, las temperaturas tan cambiantes de este verano. Y así lo hizo, no pasa del, permitidme, extremadamente pixelado logo de Windows XP (No hacía falta un logo en HD, pero podían haberselo currado un poco más), sale un error y ale a reiniciar.
Pues busca el errooor
Si, eso es lo mejor, buscar el error. Es lo que cualquier usuario de a pie debería saber hacer, buscar esos infinitos códigos de error por google, para después adentrarse en un curso rápido de 3 o 4 días de sistemas informáticos leyendo foros por internet. Total, que es un error de inicio del disco. Vale hagamos un chkdsk al disco para ver si lo podemos arreglar.
Bien. Siempre que lees las soluciones que da la gente, habla de usar el CD de Windows, usar un disco de arranque USB y cosas así. Sí, claro. A la hora de la verdad tienes que hacer rezos para que puedas iniciar el disco de arranque o el CD de Windows. No hay forma de poder hacer un chkdsk, y las soluciones que hay por internet me llevaría realizarlas días, porque tienen páginas y páginas de instrucciones, no hay ni siquiera un método que puedas tener listo en 30 minutos. Y yo paso de perder ya más tiempo.
Con mi mac en 4 años no me ha pasado esto ni una sola vez, repito, ni una sola vez. Seguro que dan errores, pero es que con Windows llega un punto en el que pulsar el botón de encendido se convierte en jugar a la ruleta rusa: Quién sabe qué pasará, ¿se iniciará? ¿dará un error de inicio? ¿tendrás a partir de ahora una nueva y maravillosa ventanita de error de por vida al iniciar el ordenador?
La gente dirá que esto son cosas del pasado, que Windows 7, que es un gran avance, que han hecho bien las cosas ahora y todo eso. Sí, lástima que la mitad de los usuarios de Windows todavía utilicen XP, un sistema que aún siendo una carroza (tecnológicamente es anticuado) puede competir en cuota de mercado con Windows 7. Quizá sea porque la gente, después de Vista, ya no se cree nada. Yo ya acabé hace años con esta historia. Pero por tener que usar Windows para según que tareas, tengo que volver de vez en cuando a recordar estos sufrimientos. Pero en fin, esto durará dos o tres días más, después cogeré el ordenador y lo tiraré al río. Seguro que de casa para cangrejos de río hace mejor función.
Por último, si te has de comprar un ordenador, no te compres uno con Windows, por tu felicidad, no lo hagas. Cómprate lo que quieras, uno con linux, con mac OS X, o una máquina de escribir si me apuras, pero no te compres Windows.
PD: Estoy aquí resignado ya, reinstalando windows xp encima de lo que tenía, y por lo tanto, borrando todo (tranquilos mi proyecto está a salvo :P). Y lo mejor de todo es que aun no consigo ni reinstalar windows. Que la barra termine es un a odisea, ya llevo 3 pantallazos azules distintos, todos referidos al kernel y a no se que historias varias, sí lo mejor para una tarde de verano. Creo que voy a encender la Xbox.
PFC – Resumen semana #3
Una semana más. Esta semana ha sido de dura lucha la verdad. Durante esta semana he estado intentando cambiar una parte importante del programa. He sudado tinta y aun no lo he conseguido del todo, no digo más. Hablo acerca de ello.
Existe una zona en el programa en la que se indica donde están colocados los wiimotes en la sala, y los ángulos de inclinación con respecto al suelo y la pared. Es esta zona negra:
Dicha zona representa la habitación o sala en la que queremos posicionar el objeto. Previamente le damos las medidas y el programa calcula el tamaño que ha de tener dicha zona negra. En concreto esta sala de pruebas tiene 5 metros tanto de largo como de ancho y unos 3 de altura.
Pues bien, clicamos el botón «Editar distribución» y entramos en la fase de edición. Ahora cuando pulsamos con el botón izquierdo del ratón sobre dicha zona negra (una PictureBox), se nos dibuja un circulo blanco que nos indica que hemos colocado un wiimote, y haríamos así para todos los wiimotes que tuvieramos en la sala. Después de eso volvemos a clicar el botón «Editar distribución» para pasar a la fase de visualización.
En esta fase, si clicamos con el botón izquierdo en el circulo recién dibujado, se nos mostrará en la zona derecha el panel del que hablé en la entrada anterior. Dicho panel nos servirá para darle las condiciones físicas de posición: La altura a la que está del suelo y los ángulos con respecto a la vertical y la horizontal.
Mientras vamos introduciendo los datos, en el PictureBox se nos va dibujando en azul un cuadrado, que nos muestra el área de visualización que tiene el wiimote que hemos colocado. En la siguiente imagen se ve mejor:
Pues bien, esto es más o menos ya lo tenía realizado y funcionaba a la perfección. El problema es las funciones que calculan el área azul, están pensadas solo para funcionar cuando el wiimote está colocado a 90º con respecto de la horizontal. Lo hice así para poder comenzar con algo, para poder comprobar si funcionaban bien los cálculos que yo había previsto. Además las fórmulas para calcular el área cuando el wiimote está a 90º son más sencillas, mientras que cuando cambia el ángulo, la cosa se complica mucho más, y por lo tanto lo dejé para más adelante. Para ahora xD.
Tenía que hacer cambios en el programa, algunos sustanciales, para que pudiera representar los distintos ángulos, no solo cuando el wiimote está colocado a 90º. Así que lo primero fue pensar en ver las fórmulas necesarias para calcular los cuatro puntos del polígono dado un angulo. La verdad es que esto lo abandoné rápidamente porque la verdad es que era bastante complicado. De hecho es todo tema de trigonometría, pero claro, por diferentes razones vi que el código se me iba a complicar, sobre todo cuando uno de esos puntos se sale de la zona negra o visible.
Así que pensé en otro acercamiento que me iba a ahorrar un poco de código. Lo que pensé fue en rotar cada uno de los puntos del polígono con respecto al centro del circulo blanco. Estuve buscando por internet para ver si alguien había hecho alguna función para hacer esto, y efectivamente lo encontré, y además en varias páginas distintas de ayuda. Con lo cual intenté implementarlo en lo que yo ya tenía hecho.
Aquí vino lo complicado. Tuve que hacer bastantes cambios en las funciones de dibujado, porque de la nueva forma, cada vez que introduzco los grados, tengo que calcular el area a 90º, para después rotarla hasta dejarla en los grados que ha indicado el usuario. Bueno pues he tenido ahí 3 o 4 días de lucha buena, y alguno que otro de desesperación xD. Tenía previsto tener esto listo en 3 días y al final llevo una semana y aún estoy retocando código, pero más o menos ya lo tengo dominado. Ahora puedo hacer lo que veis:
Ahora cuando le indico unos grados distintos a 90º con respecto de la horizontal, se ve reflejado en la zona negra. Ya solo me queda retocar algunas cosas, eso cuando hay solo un wiimote. Cuando coloco dos o más, aparecen otros problemas, pero bueno iré solucionándolos esta semana. Y si lo soluciono rápido podré por fin ponerme con el tema de la calibración de wiimotes que se me está retrasando y tengo que entrar en este tema ya mismo. La semana que viene otro poco más ;)
PFC – Resumen semana #2
Aquí llega un nuevo informe :p. Bueno esta semana ha sido un poco movida, sobretodo a partir del viernes, pero bueno he podido avanzar faena. Esto es lo que he conseguido esta semana:
- Hay una zona en el programa en la que puedo ver y modificar los datos acerca de la colocación de cada wiimote en la sala. La altura, y dos ángulos de inclinación horizontal y vertical, para saber hacia donde está apuntando el mando y calcular el área de visión de cada wiimote. Me gustan las buenas UI (User interface o Interfaz de usuario), que sean amigables para el usuario y sobretodo que no sea difícil utilizarlas; es por esto que estos días me he centrado en mejorar esta parte del programa, ya que antes estaba puesta un poco para probar. Os enseño una captura de la parte que digo:
- Los tres datos se pueden introducir vía caja de texto o mediante el control asociado que hay al lado de cada caja de texto.
- Para la altura tengo un control tipo «trackbar» el cual permitirá dar la altura por separado de cada wiimote, y cuyos límites vendrán dados por la altura de la sala, y por la altura a la que esté colocada la semi-esfera sensora que enseñé en la anterior entrada.
- Para los grados tengo un control rotatorio, un control tipo knob. De tal forma que al hacer click en alguna parte de la circunferencia automáticamente seleccionamos los grados, como si fuera el control del volumen de un altavoz. Cada uno tiene unas limitaciones físicas distintas porque los grados alfa está pensados para ir de 0 a 180 y de 0 a -180, o sea la circunferencia completa pero con signo. Y el otro, el de los grados beta, está pensado para ir de 90 a -90. Si introducimos un número en la caja de texto, el control gira automáticamente a la posición que le hayamos dado, y si supera los rangos que he dicho, pues no nos hace caso y pone el valor tope por defecto: Si introducimos 270º nos pondrá 180. Y si ponemos un número en la caja y pulsamos la tecla – una y otra vez, nos va cambiando el signo del número.
- Ya que esta semana ha sido un poco movida, he decido hacer tareas que sean menos pesadas y profundas y me sirvan igualmente para avanzar. Por eso he estado revisando la nomenclatura de todo el código que llevo escrito, pasando todo a inglés, menos los comentarios, para que todo el código esté escrito de la misma forma y no haya partes en español, otras en inglés y demás.
- Estoy implementando un control de entrada de datos de usuario. Esto es que cada vez que el usuario escriba un número de algún dato, alguna altura, algún grado o lo que sea, el programa controle que el usuario escribe números y no letras, lo que podría provocar errores.
- También estoy realizando una buena lista de tareas. Tengo una lista de tareas hecha a mano, que es la que voy usando para ver qué es lo próximo en lo que tengo que ponerme, y las tengo categorizadas por prioridades, de forma que según el tiempo y las ganas y energías que tenga, pues puedo ponerme con alguna tarea más dura e importante, o con alguna otra que pueda hacer y sea un poco más tranquila. Después todo esto lo tengo bien hecho con un software para gestión de proyectos. No uso todas las funciones del programa, pero tengo todas las tareas que tengo que hacer con la duración prevista, con la prioridad de cada tarea y separadas por tarea de tipo Hardware o Software. Va bien tener todas las tareas para, de un vistazo, ver como va avanzando el proyecto.
PFC – Resumen semana #1
Bueno poca cosa esta semana, comprobar que todo funcionara igual que cuando lo dejé la última vez y ponerme a diseñar la matriz de leds infrarrojos. El mando es capaz de ver un led infrarrojo, el problema es que dependiendo de la distancia y el ángulo en el que se encuentra el led, puede estar relativamente cerca del wiimote y este no lo ve, con lo cual era un problema importante ya que reducía bastante el rango de visión efectivo del wiimote.
Por lo tanto pensé en hacer una matriz de leds, o sea, no solo un led, sino varios juntos y en distintos ángulos, de forma y manera que el wiimote ve el conjunto de leds como un solo punto de luz, y como hay varios leds apuntando a varias direcciones. He hecho dos posibles modelos de esta idea, ahora con las fotos lo veréis mejor:
Como veis no tiene ningún misterio. Simplemente comentar que he hecho dos modelos por la siguiente razón: Hay uno de los modelos que tiene los LED’s incrustados en una pelota de tenis de mesa cortada por la mitad. Pensé que distribuyendo los LED’s alrededor de una superficie esférica iba a conseguir una mejor recepción por parte del wiimote. Este modelo todavía debo comprobarlo
Pero luego pensé en hacer la inversa, esto es crear la matriz de LED’s, doblándolos para cambiar el ángulo de cada uno de los LED’s y entonces la semiesfera resultante de la pelota de tenis de mesa, ponerla encima de los LED’s. De esta forma perdería potencia, porque estaría tapando la luz de los LED’s con un objeto, pero pensé que haciendo esto conseguiría un efecto difuminador, y el wiimote vería todos los LED’s como uno solo.
El caso es que al final, el primer modelo de los dos que veis, funciona bien sin la pelota de tenis de mesa encima, o sea que el wiimote en lugar de ver muchos LED’s, al estar tan cercanos entre sí, solo ve un punto infrarrojo, con lo cual desestimé el poner la pelota de tenis de mesa encima ya que así no perderé luminosidad.
Y eso es todo por ahora. Mañana me pondré a hacer cambios en el programa, ya tengo varias cosas que estaban un poco cogidas con pinzas, pero que ahora podré refinar mejor. Y estoy también con la escritura del código para calibrar los wiimotes, a ver si lo vuelvo a plantear ya que esto es bastante esencial para el proyecto.
Y aunque son muy sencillos, incluyo los esquemas de los dos circuitos que he enseñado y con eso hasta otro día :D
PFC – Volvemos al trabajo
Una vez acabado Junio vuelvo a ponerme con mi proyecto de final de carrera. Alguna semana de vacaciones habrá de aquí a septiembre claro :p, pero la idea es darle un empujón importante al proyecto durante el verano, para poder centrarme a partir del próximo curso en memorias y retoques finales. Ya he hecho una lista con tareas que tengo que llevar a cabo, tanto en la parte de software como la de hardware, para así tener una ruta que seguir.
La idea es hacer una entrada cada semana para poder ir explicando los avances que voy logrando (mi director de proyecto lo agradecerá), y dependiendo de como avance el proyecto iré colgando algunas fotos o quizás algún video. Tengo pensado ya un lugar en el que poder hacer pruebas de forma cómoda para así ir pudiendo probar si lo hecho funciona o no sirve para nada.
De todas formas tengo algún que otro proyecto menor para este verano, así que quizás también hable de ello aquí. Y por supuesto tengo que hablar aun más sobre nuestro olvidado robot, así que cuando quiera desconectar un poco del PFC (no mucho xD) seguiré escribiendo sobre estos otros temas.
Nos vemos!
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 lineaGira a la izquierdaSi sensor izquierdo no ve lineaGira 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:
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:
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 – Concurso ETSEBOT
Este viernes es el gran día para los que estamos dentro del Taller de Robótica Móvil. Es el día que se celebra al fin el concurso ETSEBOT’11. Ya tenemos el robot montado y funcionando de forma correcta desde hoy, con lo cual, hasta el concurso podemos ir ajustando el robot. La verdad es que por nuestra parte si que había fe en que el robot funcionara tal y como habíamos pensado en nuestra mente. No así en la de los profesores, ya que creían que quizás tuviéramos muchos problemas, y no fueramos capaces de dar una sola vuelta.
Y tenían razón, en parte. Tuvimos muchos problemas, de todos los colores, pero los hemos solventado todos y el robot no solo da una vuelta al circuito de forma correcta, sino que lo hace tan solo unos 5 segundos más lento que el récord de la pista, lo que actualmente nos sitúa entre los mejores del taller de robótica. Así que ganemos o no el viernes, por el momento, éxito.
Ya sabemos que además de un suculento bocadillo, hay premios en metálico (más suculentos que cualquier embutido :p) para los vencedores de las distintas categorías, así que a ver si con los ajustes a realizar que tenemos en mente podemos rebajar los tiempos un poquito más, y conseguimos premio en alguna categoría (no se puede en las dos, lástima xD).
Mañana a ver si puedo actualizar con los últimos avances y quizás suba algún video del bicho. Por cierto, decir que el robot tiene nombre como resultado de unos problemas que tuvimos. Probamos un programa que creíamos que iba a hacer que el robot funcionara correctamente, que no se quería grabar en el pic, era increíble, así que llamamos a ese programa «maldito» xD. Al final, después de rehacer el programa durante un dia o dos, conseguimos que el pic se grabara, a partir de entonces, llamamos al programa «bendito» jaja, así se llama el robotico, «bendito».