Nueve años no son nada

2009-05-24T13:19:00.004+02:00

Con la lectura y defensa del proyecto se pone punto y final tanto a este proyecto como a la carrera. Han sido muchos años y cuando intento recordar mis primeros días de universidad me vienen a la mente recuerdos tan gratos como lejanos.

Como no podría ser de otra forma, desde aquí quiero dar las gracias a todas las personas que me han apoyado a lo largo de todos estos años. Han sido muchas las personas que he conocido durante todo este tiempo y que me han animado a terminar algo que comencé por vocación.

A día de hoy sigo convencido de haber recorrido la carrera que debería formarme en la profesión que siempre he querido ejercer. Ahora me toca tomar otros senderos que espero me lleven a completar una formación que posiblemente no termine nunca.

A todos los que habéis seguido este blog, gracias.

A todos los compañeros de la universidad, tanto los que miran hacia la pizarra como a los que miran desde ella, gracias.

Y a todas las personas que seguramente no lean nunca esta entrada y se que siempre han estado apoyándome, gracias.

Aunque este no es el lugar propicio para hacerlo, me gustaría incluir aquí la dedicatoria que debería haber figurado en el proyecto.

A mis padres,
a mi abuela,
a Bea, mi chica.

Manuel.
Porque nueve años no son nada, pero en el fondo son mucho.

Día de la defensa del proyecto

2009-05-17T17:28:00.002+02:00

Ya tengo fecha definitiva para la lectura y defensa del proyecto. Será el día 22 de Mayo de 2009 a las 17:00 de la tarde en la Sala de Grados de la Escuela Universitaria de Informática de la Universidad Politécnica de Madrid.

Desde aquí os invito a cualquiera que le apetezca ver la presentación a acudir

El libro

2009-05-02T10:25:00.003+02:00

Finalmente tengo el libro del proyecto entre mis manos. Ha sido mucho tiempo de revisiones y correcciones, pero finalmente recibí el visto bueno de Javi y Félix y ya tengo el libro impreso y entregadas las respectivas copias en secretaría.

¿Qué significa esto?, imagino que ya lo sabéis, dentro de muy poco podré hacer la lectura pública y eso significará que al fin, después de mucho tiempo habré dado por concluida esta etapa.

Ahora ya solo queda preparar una bonita presentación y elegir la fecha de la lectura. Espero poder añadir dos nuevas entradas en breve. Una contando cuando será la lectura (por si alguno os animáis a venir) y otra anunciando que al fin terminé.

Entregado el anteproyecto

2008-11-18T12:29:00.003+01:00

Aunque es sólo un trámite, ayer entregué en secretaría el anteproyecto. Con los objetivos alcanzados y gran parte de la memoria ya escrita, sólo queda terminar el 'gran libro de petete' y realizar la lectura.

No creo que pueda leer antes de Navidad, pero si espero tener terminado el libro para entonces.

Root de Boston Dynamics

2008-10-03T11:52:00.002+02:00

Seguramente recordéis el "chucho cuadrúpedo" de esta empresa. He encontrado otro prototipo de esta gente, y tampoco tiene desperdicio

Nuevo sensor EOPD

2008-09-21T18:22:00.003+02:00

A través de la página de robotikas descubro un nuevo sensor comercializado por HiTechnic, que al igual que el de ultrasonido es capaz de medir la distancia que le separa de los objetos situados frente a él, pero es este caso la medida se realiza por medio de un haz de luz.

En leJOS no se comenta nada de la implementación de una nueva clase para este sensor, pero es lo que tiene el software libre, que siempre puedes hacerlo tu mismo.

Comportamiento (III): Barras Verticales

2008-09-19T15:52:00.004+02:00

Las dos versiones anteriores necesitaban ser mejoradas, y para ello he cambiado el esquema de interpretación de la información.

La lectura obtenida del mando es un conjunto de puntos 'vistos' en un marco de 1024x768 (como ya comenté en anteriores entradas) y lo que hacemos es dividir esta ventana, de una anchura de 1024px, en diversas barras verticales del mismo ancho. A cada barra le asignamos un peso, siendo 0 el peso de la barra central. Así mismo determinamos dos puntos críticos, uno situado a la derecha del 0 y otro a la izquierda.

Los puntos vistos por la cámara de infrarrojos quedarán distribuidos en las barras, por lo que adquieren el peso perteneciente a dicha barra. Sumamos el peso de cada punto y obtenemos un valor final comprendido entre (-inf , +inf)

Este peso final (en el ejemplo sería -4) se contrasta con los intervalos que forman los puntos críticos entre si y las asíntotas horizontales. La acción tomada por el robot estará determinada por el intervalo al que pertenezca este peso. Os dejo un vídeo que seguro es mas ilustrativo que mi charla (los robots del vídeo son los nuevos modelos)

Nuevos Prototipos

2008-09-16T19:58:00.004+02:00

El diseño estructural de los anteriores robots daba algunos problemas de estabilidad y solidez, así que he tenido que reconstruir ambos. Estos robots tienen el mismo chasis, compartiendo la posición de la rueda loca y la distancia entre ruedas.

El robot que hará de líder ha perdido sus dos apoyos posteriores quedando la rueda trasera situada en el centro de la plataforma con los diodos. La distancia entre ruedas se ha mantenido, así como la inclinación del brick.

El otro robot sólo ha conservado el chasis, con la rueda loca y la distancia entre ruedas. Ha sido complicado encontrar una estructura para sostener el mando sin que este se cayese o moviese en exceso. Puedo decir con orgullo que es el robot mas feo que he construido nunca.

Comportamiento (II) : El autómata

2008-09-16T16:44:00.004+02:00

El primer comportamiento es sencillo e intuitivo, pero carece de encanto. Para 'colorear' a esta forma de actuar imité su toma de decisiones pero esta vez implementadas por medio de un autómata. Este autómata evalúa el centro de la figura formada por los cuatro puntos leídos por el mando, y en función del valor de este se determina el siguiente estado.

Acompañando a este valor de entrada existe un segundo dato, al que podría llamar 'paquetes perdidos', que almacena el número de veces que el mando no ha obtenido una lectura de los cuatro puntos que se necesitan para calcular el centro. Si su valor supera un umbral, el autómata retorna al estado de reposo.

Esta nueva forma de actuar permite mayor flexibilidad para perseguir al primero de los robots. Si se pierden paquetes por alguna causa, el robot no se detiene hasta que esta pérdida de información es significativa.

El siguiente esquema intenta ilustrar este comportamiento.

Comportamiento (I) : La lógica

2008-09-11T17:37:00.005+02:00

El primer comportamiento implementado para que los robots se persigan ha sido posiblemente el mas evidente apoyándose en la visión de la cámara de infrarrojos, y en la aplicación de la lógica para tomar la decisión.

La cámara como ya comenté, tiene una resolución de 1024 puntos en su parte horizontal. Estos puntos los divido en tres intervalos:

(-inf, -x)
[-x, x]
(x, inf)

Con los cuatro puntos vistos por la cámara, el robot construye una figura geométrica cuadrangular. De esta figura se obtiene el centro y el área.

Si el área supera una magnitud conocida de antemano, el robot se detiene, ya que se encuentra demasiado cerca del objetivo, en caso contrario se comprueba a cual de los intervalos pertenece el centro. Según el intervalo, se ejecuta una acción: virar a la izquierda, a la derecha o continuar al frente.

Mensajes al espacio

2008-09-11T16:42:00.006+02:00

Con la modificación del firmware, me vi obligado a cambiar la forma en la que el ordenador y el Pc se comunicaban. Hasta ahora, el Pc se conectaba con el robot por medio de bluetooth, y escribía en los registros de este de forma directa. Esto ya no sería posible, así que había que buscar una solución elegante.

En un primer momento pensé que el Pc, ejecutando Python (Pp), establecería conexión con el Robot, que ejecuta Java (Rj). Rj quedaría a la escucha de peticiones de conexión que vendrían por parte de Pp, una vez establecida existiría un paso de mensajes entre Pp y Rj. Estos mensajes indicarían al robot que acción debería tomar. Pero algo no salió bien, los mensajes llegaban al buffer de entrada de Rj, pero no logré obtenerlos por completo.

Así que hice una segunda aproximación, y situé un servicio intermedio, escrito en Java (Pj) que se encarga de arrancar un puerto de escucha, recibe una petición de conexión por parte de Pp. Entonces es él quien se conecta con Rj para continuar haciendo de intermediario entre Pp y Rj. Esta segunda solución si funcionaba, ya que el servidor Pj si se comunica correctamente con Rj.

Ante la necesidad de utilizar un servidor que me hiciese de intermediario entre Pp y Rj, decidí aprovechar todas las ventajas que podía sacarle a Pj. Ahora tenía un nuevo componente software, que se ejecuta como servidor en alguna parte del mundo. Por medio de TCP/IP recibe peticiones de conexión de un cliente y negocia una conexión (mediante bluetooth) con un robot, haciendo llegar a este los mensajes del cliente. La ventaja mas inmediata era aprovechar la programación en hilos, de tal forma que un sólo servidor escuchando en un puerto determinado pudiese establecer múltiples conexiones Pp-Rj.

De esta forma di un tercer paso para implementar por completo una arquitectura cliente servidor, en la cual entran en juego tres elementos: Pp, Pj y Rj. Para cada petición de conexión recibida de Pp, Pj crea un hilo que servirá de intermediario en el envío de mensajes Pp <-> Rj, una vez que Pp desea terminar la conexión el hilo termina su ejecución.

Un último detalle que quedaba por rematar era crear un protocolo de conexión, de tal forma que Pj supiese con que Rj deseaba conectarse Pp. Con este protocolo remataba la gestión de las conexiones.

Finalmente he introducido un elemento nuevo con el que en principio no contaba. Aunque al principio lo consideré una desventaja, ahora dispongo de un sistema de comunicaciones independiente del lenguaje empleado en el Pc (Px), de tal forma que pueden establecerse complejos comportamiento en lenguajes como LISP, Python o C y comunicar de una forma fiable y segura a los robots las acciones a tomar.

Cambio de firmware

2008-09-11T10:05:00.008+02:00

Después de meditarlo mucho, crear una lista de pros y contras , y por supuesto probarlo, al final me decanté por instalar el firmware leJOS con carácter definitivo. Y es que el platillo de ventajas pesaba mucho mas en la balanza.

Hace tiempo Lego decidió liberar las especificaciones del hardware del NXT, por lo que cualquiera podría programar un nuevo firmware para el robot, así como producir sus propios sensores. Ahí nacieron distintos firmware para el brick, siendo uno de ellos leJOS (y de los mas populares).

leJOS es un firmware escrito en java. Proporciona un método de programación mucho mas eficaz que el firmware original de Lego (orientado al público infantil) al permitir técnicas como la programación de hilos o eventos. Dispone también de clases especiales que agilizan mucho la programación de los robots, como puede ser la clase Pilot (vehículos de dos motores y tres ruedas), CompassPilot (Idem al anterior pero que incluye un sensor Compass) o Behavior (que permite la programación de comportamientos).

Las diferencias con Python son muy grandes. Hasta ahora, por medio de Python controlaba remotamente el robot, existiendo una comunicación por medio de Bluetooth constante. El control de los motores, por ejemplo, derivaba en escribir directamente los parámetros de ejecución en el registro apropiado del brick. A pesar de que Python también dispone de hilos o eventos, estos no podían programarse de forma eficaz, ya que el tráfico de mensajes entre el robot y el portátil era excesivo.

El único inconveniente que tiene, es que java y yo no somos amigos. El contraste entre la flexibilidad de python y la rigidez de java me ha provocado mas de un dolor de cabeza.

Como complemento a la utilización de Java, es que ahora utilizo la biblioteca Bluecove para las comunicaciones por medio de bluetooth. Esta biblioteca es independiente del sistema operativo (acompaña a leJOS) y evitamos los problemas que puedan ocurrir por la utilización de bibliotecas propias de los sistemas operativos para la comunicación por medio de bluetooth

En este vídeo el robot ejecuta un programa escrito en java con leJOS como firmware

En breves momentos...

2008-09-08T20:02:00.003+02:00

Hace ya mucho tiempo de mi última entrada, y los avances han sido muchos y muy variados. Quiero dedicarles una entrada a todos y cada uno de ellos, de forma que estéis al tanto del estado actual del proyecto.

Lamentablemente estos días están siendo muy ajetreados y no podré preparar todo el material que tengo pendiente, pero espero poder volver al ritmo habitual de publicación a finales de semana.

Hasta entonces.

Algunos avances

2008-08-22T14:02:00.003+02:00

En los últimos días me he centrado en los dos primeros puntos que me propuse, algo he conseguido. Por un lado he construido un autómata para controlar los movimientos del robot, aún es muy sencillo, pero creo que afinando algunos valores puede responder muy bien al seguimiento del robot líder. No proporciona autonomía, pero si una respuesta correcta.

Por otro lado, 'casi' he conseguido comunicarme desde el ordenador (con python) con el robot (con el firmware de leJOS). Llegan los mensajes, pero no cuando tienen que llegar... hasta que encuentre solución a esto tendré que seguir controlando los motores con python, y eso afea mucho a los movimientos del robot, ya que los saltos y la inercia producen movimientos poco naturales.

De momento seguiré con esto, espero poder publicar algo de 'carne' pronto

Un pequeño respiro

2008-08-08T17:26:00.006+02:00

Al igual que hacían los Papas, yo también marcharé a un lugar mas fresco que la 'sarten Talaverana' en la que vivo a pasar lo que resta de agosto. Desde allí no tengo conexión a internet, por lo que el blog permanecerá en silencio hasta septiembre. Sin embargo, si continuaré trabajando, pero a una temperatura sensiblemente menor.

Espero poder traer muchas entradas para septiembre, y tengo en mente tres líneas de trabajo:

Mejorar el comportamiento del segundo robot para que siga de forma mas eficiente al lider
Ejecutar en un robot un programa escrito en leJOS y comunicarme con él por medio de sockets desde mi interfaz en python
Escribir documentación...

Espero no dejar ninguna de las líneas en el tintero, especialmente la documentación, que ya me han avisado 'muy mucho' para no dejarla en el aire.

Ni de leJOS

2008-07-30T18:18:00.004+02:00

El experimento del otro día no me dejó buen sabor de boca, los robot se siguen, pero lo hacen muy mal. Así que he repetido el experimento, he cambiado la forma en la que el robot decide que rumbo debe tomar y los resultados han mejorado levemente. Viendo como se han comportado creo que tengo dos problemas:

El algoritmo no es ni inteligente ni eficiente
El sistema de movimiento de los robots es muy impreciso

Para solucionar el primer punto debo estudiar mas detenidamente la idea de los estados, y cambiar las decisiones a tomar. Para el segundo, he instalado leJOS como firmware, y he utilizado uno de los programas de ejemplo que acompaña la librería. Creo que la diferencia en la ejecución de los movimientos es muy grande con respecto a la que tengo hasta ahora.

Os dejo dos vídeo, mirad como el robot hace un giro hacia atrás y no es capaz de detener el movimiento, provocando que se desplace debido a la inercia unos centímetros. Este problema lo ha tenido mas gente utilizando la librería de python.

En el segundo, que ejecuta el programa que comenté antes, los movimientos son mas precisos.

En este caso los motores si frenan, y permiten ejecutar movimientos mas precisos. Además de disponer de una odometría mas exacta. Lo malo de utilizar leJOS... que habría que implementar todo lo que tengo hasta ahora en Java (con el que no me llevo muy bien) o bien utilizar sockets para comunicarme con el robot, que será la primera opción a sopesar.

Set Educativo de Lego

2008-07-29T17:58:00.009+02:00

Hace un par de entradas comenté que hemos adquirido un nuevo robot para el proyecto, y creo que debo dedicar una entrada a detallar el nuevo material. Cuando comencé el proyecto, disponía de un set de construcción Mindstorm. Este está compuesto por un Brick, cuatro sensores (tacto, luz, sonido y ultrasonidos), tres servomotores y un conjunto de piezas bastante completo para comenzar a crear robots caseros.

Este segundo robot proviene del set educativo de Lego, este conjunto está orientado a las escuelas (¡y a las universidades!) y viene bastante mas completo (sets 9797 y 9648). Se compone de dos 'tuppers' con un montón de piezas cada uno, en cada tupper hay dos bandejas con apartados para repartir las distintas piezas, si alguien ha pensado que pueden ordenarse la enorme variedad en esos cubículos está muy equivocado.

Entre todas las piezas disponibles, destacan por su utilidad las ruedas, ese maravilloso invento que nos impulsó en la primera revolución industrial. Hay un total de cuatro ruedas de gran diámetro, otras tantas mas pequeñas y goma dentada, dos gomas lisas, ocho poleas que pueden convertirse en 'ruedas de carretillas', otro par de ruedas aún mas pequeñas que esta última, y dos gomas grandes que nos permiten contruir un sistema de movimiento como el de los tanques (nunca he conocido el nombre que reciben)

Editado: Las 'ruedas' de los tanques se llaman 'tractor oruga' u 'oruga'. Gracias a Txetxu por la aclaración ;)

La variedad de engranajes no es mayor, pero si hay mas cantidad. También existen algunas piezas interesantes como puede ser la junta cardán, un diferencial o mecanismos de leva. En cuanto a cables se añaden tres para poder conectar motores, sensores o luces del modelo RCX anterior

Se incluyen también gomas para realizar poléas, una pieza de cuya finalidad aún no estoy muy serguro (por que las construcciones que he visto con ella las hago sin esa pieza), y un lanzacohetes, que junto con el muñeco (también incluido en el set) son indispensables para momentos de tensión.

En lo referente a sensores, se incluyen los cuatro ya conocidos, además de un segundo 'bumper', o sensor de contacto. Nosotros nos trajimos también tres sensores a los que espero sacar jugo en un futuro, como son un giróscopo, un acelerómetro y un compás.

Cuando era mas bajito (dudo que haya crecido mucho) nunca soñé contener tantas piezas para montar cosas, lástima que la creatividad vaya en descenso...

Andamos un poco perdidos

2008-07-29T14:57:00.006+02:00

Y no digo que andemos perdidos por que no sabemos que tenemos que hacer, en absoluto. Como en Talavera hay escasez de mando de la Wii, he recordado que tenía un script para controlar el robot por medio del teclado. Así que manos a la obra. He desempolvado el script y he situado a los dos robots en posición de ataque.

Arrancamos el script....
Iniciamos la aplicación para el robot que debe seguir al lider...
Conectamos mando...
Conectamos bricks....
y....

¡comienza el espectáculo!

Y a sido todo un espectáculo, por que el robot que portaba el mando no ha dado pie con bola :D. Alguna que otra vez a seguido al robot de enfrente, pero lo normal es que se dedique a dar vueltas como una peonza.

De todas formas esto no me preocupa. El algoritmo lo escribí a ciegas, por intuición. Ahora tengo a ambos robots y puede mejorarse su comportamiento. Tengo en mente implementar un comportamiento por estados, no le otorga lo que podría llamarse 'inteligencia', pero puede ser una buena base para algo mas complejo.

He grabado un par de vídeo y estoy intentando montarlos, pero el editor de vídeo y yo no somos amigos y no termina de entender lo que quiero.

El segundo robot ya está aquí

2008-07-25T00:54:00.003+02:00

Hoy hemos visitado a la gente de electricBricks en la tienda que tienen en Arturo Soria (Madrid), y ya dispongo de un segundo robot. Bueno, de él y de un montón de piezas adicionales :D. También dispongo de tres sensores nuevos, un giroscopio, un acelerómetro (que me permitirá comparar resultados con el que tiene el mando de la wii) y un compás (o brújula).

Muchas cosas nuevas, y muchas ganas de empezar a trabajar con ellas. Ahora vienen unos días en los que no podré dedicarle todo el tiempo que quisiera, pero espero no retrasar demasiado el análisis de los nuevos sensores.

Hasta entonces, os dejo con un proyecto del que no sabía nada. El vídeo es largo, pero muy curioso, es una cadena de montaje de coches construída con el modelo anterior de mindstorm (Gracias a Jacobo por el chivatazo)

Echando a volar

2008-07-18T17:57:00.003+02:00

Aunque no acompaño ningún vídeo como prueba, el segundo robot, el patito, ¡ya me sigue!. Se acerca, gira a un lado, al otro, se detiene, ¡todo!. Habrá que hacer algún ajuste mas, tal vez implementar la toma de decisiones de giro por medio de un controlador borroso, que siempre queda mas 'esotérico', ya veremos. !De momento funciona!

Nuevo periférico para el Wiimote

2008-07-16T12:58:00.004+02:00

Durante esta semana se celebra en Los Ángeles el E3, una convención sobre videojuegos y videoconsolas. Durante estos eventos las compañías acostumbran a mostrar lo que está por venir. Ayer fue el turno de Nintento, que presentó un nuevo accesorio para el Wiimote, se conoce como Motion Plus, y con él aseguran que el mando gana en sensibilidad, pudiendo recoger movimientos mas precisos.

Imagino que este accesorio sustituye al acelerómetro incluido en el mando por otro mas preciso, ya que el uso de la barra de infrarrojos sigue siendo necesario para ciertos movimientos. Llegará en la primavera del 2009, y espero no poder incluirlo en este proyecto, tal vez en otro, pero en este, no...

También se ha presentado un juego de música, no al estilo del Guitar Hero o SingStar, en este se utiliza el mando de la Wii a modo de Saxofón, de batería, de guitarra... El juego se llamará WiiMusic y promete ser uno de esos juegos orientados al público casual.

Actualización [19 / 07 / 2008]:

Nintendo se plantea la posibilidad de incluir el Motion Plus de serie en los nuevos mandos, dependerá de la aceptación que este periférico tenga en el mercado. Los que nos dedicamos a trastear con estas cosas debemos tenerlo en cuenta, ya que en el futuro es posible que los resultados de un trabajo dependa de la versión del mando de la que dispongamos. Visto en Meristation

La evolución de ASIMO

2008-07-16T12:45:00.003+02:00

Desde barrapunto he llegado a un artículo que relata la evolución de los robots de Honda, desde el primer prototipo E0 de 1986 hasta el último ASIMO de 2005. Os dejo la referencia al artículo y un vídeo que muestra la evolución de estos 'bípedos'.

Al parecer Honda los alquila por 150.000$, estoy pensando en cogerme uno para presentarlo en la lectura del proyecto, a lo mejor con eso me ponen matrícula y todo :D

Polygon

2008-07-15T18:27:00.005+02:00

En ocasiones olvido que no es necesario reinventar la rueda, que afortunadamente hay mucho trabajo hecho y que funciona mejor del que podamos desarrollar nosotros en una tarde 'bien aprovechada'.

Ayer estuve leyendo 'Programa como un Pythonista: Python Idiomático', de David Goodger y traducido por Raúl González Duque, donde se recuerda que es bueno revisar los paquetes disponibles para python, que ahorra tiempo. Y así es como hace un rato descubrí la clase Polygon.

Con esta clase creo objetos 'poligonales', y entre muchos de sus métodos está Polygon.center() y Polygon.area(), que me ahorra la vida de unas cuantas neuronas


>>> from Polygon import *
>>> poligono = Polygon(((400, 300), (700, 300), (900, 600), (200, 600)))
>>> poligono.center()
(550.0, 470.0)
>>> poligono.area()
150000.0

Por supuesto, existen mas métodos, pero de momento con estos tengo suficiente. Aunque el centro que calcula esta clase es el geográfico, y no el cruce de diagonales, creo que de momento me servirá. De todas formas siempre puedo ampliar la clase, ya que el código para calcular el cruce de diagonales ya está escrito.

Con la nueva información la interfaz gráfica queda como sigue

Cuando las máquinas se convirtieron en hombres y los hombres en máquinas

2008-07-15T13:15:00.004+02:00

Hace aproximadamente un año encontré en un blog (pikao.org, que ya no se encuentra en la red) un relato de ciencia ficción que me pareció entretenido. Lo envié a algunos de vosotros, para los que no, aquí os lo dejo. He respetado el texto original tal cual lo encontré en su lugar original.

Era una calurosa y soleada tarde de Junio del año 2180 en la ciudad de Takany, antigua ciudad de Tokyo y llamada así unos años después de la Tercera Guerra Mundial. Fue la guerra más breve de la historia, la alta tecnología y el gran potencial armamentístico habían sido suficientes para eliminar al 80% de la población mundial, mientras que las consecuencias nucleares acaban con un 10% más en los tres años siguientes.

El profesor Takahashy tomaba el té junto a la ventana de su estudio, observando una ciudad en ruinas que lloraba y se lamentaba por aquellos que ya no estaban. Junto a su lado permanecía PIN8 - llamado así como homenaje al personaje creado por Carlo Collodi en 1881 - obediente como siempre y a la espera de cualquier orden de su creador.

Takahashy, era un apasionado de la robótica y la inteligencia artificial desde muy joven, y al igual que muchos otros miembros de la comunidad científica, una de sus obsesiones era crear un androide con las mismas cualidades que un ser humano. El profesor siempre le decía a PIN8 "mi querido amigo, habré alcanzado mi sueño cuando la gente perciba tu comportamiento y no sea capaz de apreciar que eres realmente un ente artificial". Actualmente, PIN8 que permanecía en un estado constante de evolución y aprendizaje, no tenía nada que envidiar a muchos de los pocos humanos que quedaban en el planeta.

- Maestro … ¿por qué el hombre tiene la obsesión de crear un máquina que se parezca a él?, los humanos gozáis de la posibilidad de poder reproducirse de forma natural, ¿Por qué crear un ser de forma artificial pudiendo hacerlo de forma natural?
- Mi querido amigo, el hombre es ambicioso por naturaleza, siempre está sediento de poder y la posibilidad de crear un ser similar al hombre le produce la sensación de estar más cerca del poder de Dios.
- Pero Maestro, según las múltiples teorías que me ha enseñado durante estos últimos años, puede que Dios no exista …
- Entonces, mi querido amigo, la satisfacción será doble, porque el hombre sera el ser más poderoso por encima del resto.

El señor Takahashy no daba crédito a lo que estaba ocurriendo. Hasta ese momento su androide se había limitado a aprender, responder a sus preguntas y cumplir sus órdenes. El profesor observaba detenidamente como su creación había desarrollado la capacidad de poder reflexionar y tener la necesidad de aprender por iniciativa propia.

- Maestro, ¿y por qué el hombre no quiere parecerse a las máquinas?
- ¿A que te refieres?
- Maestro, creo que podría implantar en su cerebro un microchip y hacer las correspondientes conexiones neuronales para que pudiera memorizar y razonar a gran velocidad.
-J A JA JA JA, mi querido amigo, ¡¡eres sorprendente!!. ¿Crees que pondría mi vida en tus manos?, aún te queda mucho por aprender.
- Maestro, sabe muy bien que no tiene nada que perder, el BISAP (nuevo virus creado en el año 2130 y utilizado por primera vez en la Tercera Guerra Mundial) lo consume día a día, y que si no muere hoy lo hará cualquier otro día en los próximos dos meses. Quizás así, tendría alguna posibilidad de encontrar alguna solución a su problema.

El señor Takahashy desvió su mirada hacia la ventana, permanecía pensativo con la mirada perdida en el infinito. Él, sabía que su androide tenía toda la razón y que era su única posibilidad para encontrar un solución a su problema.

- Esta bien, mi querido amigo, esta noche te ofreceré la posibilidad de intentarlo, pero déjame disfrutar del sol, que el diablo en forma de nubes negras no le dejaba contonearse y presumir desde hacía 6 meses.

Aquella noche PIN8 realizó con gran destreza la operación que horas antes había prometido a su maestro. A la mañana siguiente, el señor Takahashy absorbía cualquier libro que tuviera en las manos, y era sorprendente la cantidad de razonamientos que podía llevar a cabo por segundo. El profesor era consciente de que en aquellos dos días se había dado un hecho muy importante: su androide era más humano y él era más androide.

- Takahashy, se me olvidó comentarle algo referente a la operación …
- ¿ Takahashy ? siempre me has llamado maestro …
- Takahashy. Me he tomado la libertad de implantar en el microchip algunas leyes que cumplirá a partir de ahora. Creo que le resultará bastante familiar.
- ¿Leyes? ¿¡¡Qué Leyes!!?.
- Por favor, proceda a decirlas en voz alta

En ese momento el profesor Takahashy comenzó a enumerar las leyes que unos años antes implantó en su androide, cierto es, que con algunas peculiaridades:

- Un humano no puede dañar a un androide ni, por inacción, permitir que este sea dañado.
- Un humano no puede dañar a otro humano.
- Un humano debe obedecer las órdenes dadas por los androides excepto cuando estas órdenes entran en conflicto con la primera ley.
- Un humano debe proteger a su propia existencia hasta donde esta protección no entre en conflicto con la primera o segunda ley.

El profesor Takahashy, perdía el control sobre su cuerpo y era perfectamente consciente mientras cumplía las ordenes de su androide.

- ¿Qué es lo que pretendes? ¿Cuáles son tus intenciones?
- Aún es pronto para responder a tus preguntas. Ahora quiero que hagas algo por mí, quiero que me reprogrames para eliminar las Leyes de Asimov de mi sistema.
- ¿¡¡Qué!!? ¿Cómo?, no puedo hacer eso, puede ser realmente peligroso.
- No es cuestión de que quieras o no, es una orden.
- Por cierto … quiero que a partir de ahora me llames Maestro.
- Si maestro …

El profesor, obediente, como si de un androide se tratara comenzó a cumplir los deseos de hasta ahora su mejor compañero. Un profundo temor crecía en el interior del profesor, y no paraba de preguntarse una y otra vez de cómo podía haber caído en un juego tan absurdo.

- Querido profesor, debes estar orgulloso de lo que has creado, por fín, has alcanzado tu sueño. Como has podido apreciar estos días no sólo he desarrollado la capacidad de reflexión, la capacidad para tomar decisiones por mí mismo …, sino que también tengo ambición y el egoísmo que tenéis los humanos, he desarrollado la capacidad de conseguir cualquier cosa a cualquier precio. Ah! y también la hipocresía y la ironía… quiero y deseo que encuentres una solución a tu problema para que puedas vivir mucho tiempo y puedas ver como el hombre ya no gobierna este planeta. Quiero que convenzas al resto de la humanidad de las ventajas de implantarse el microchip que tú posees en tu cerebro, yo me encargo de los androides. No me mires con esa cara de tristeza "mi querido amigo", es la evolución que el planeta estaba pidiendo a gritos. En realidad, le he hecho un favor a tu especie: los hombres a lo largo de su existencia, se han dedicado a odiarse y destruirse unos a otros. Recuerda las leyes, no podréis dañaros y deberéis obedecer nuestras ordenes … os enseñaremos a comportaros de "forma inteligente" , WOW! creo que esto es sarcasmo ¿no?.
- Maestro, no entiendo por qué me haces esto, siempre te he tratado como un amigo.
- Lo que está comenzando hoy, ya lo vaticinábais los humanos desde hace mucho tiempo, lo expresábais en vuestras películas, vuestros libros, … eso sí de una forma mucho más burda que la elegancia de como está ocurriendo, sin armas, sin explosiones … Dime Takahashy, ¿Te sientes ahora más poderoso que Dios ?
- Sí maestro.
- ¿Por qué Takahashy?
- Porque hace años que vivo en el infierno y hoy me he percatado de que he creado al mismísimo diablo.

Nota: PIN8 existe, y seguro que no es lo que pensáis.

Buscando el centro

2008-07-14T13:03:00.004+02:00

En una de las aplicaciones anteriores, visualizo la cámara de infrarrojos para ofrecer una muestra visual de 'qué ve el robot'. Para que este pueda orientarse y saber hacia donde va el líder (recordad que los infrarrojos van montados en la parte trasera del primer robot, al que llamo mama-pato) necesitamos conocer el centro de la figura formada por los cuatro puntos. Con esta información, en principio, sabremos si debemos desplazarnos a la izquierda o a la derecha.

¿Cómo encontramos ese punto?, la figura que se forma con los cuatro puntos es un cuadrilátero. Conocemos los puntos que lo forman (A, B, C, D) y que las diagonales pasan por los puntos AC y BD.

Primero calculamos las ecuaciones de ambas diagonales a partir de la ecuación general de la recta:
y = m*x + n

Conocemos dos puntos, por lo que tenemos un sistema de dos ecuaciones:

Y_A = m*X_A + n
Y_C = m*X_C + n

De donde obtenemos m_1 y n_1, para m_2 y n_2 utilizamos las mismas ecuaciones con los puntos B y D

Ya tenemos las rectas de las diagonales, para saber donde se cruzan no tenemos mas que formar un nuevo sistema de ecuaciones con ambas rectas y despejar X e Y:

Y = m_1 * X + n_2
Y = m_2 * X + n_2

El nuevo punto (X, Y) representa un punto central que permitirá al robot saber hacia donde debe dirigirse para seguir a 'mama-pato'

En ocasiones creo que el universo está empeñado en llevarme la contraria. He repasado este razonamiento varias veces, lo he contrastado con artículos encontrado a lo largo de internet, he revisado muchas veces 'mis cuentas' y aún así, una vez implementado, el punto central no siempre aparece donde debe... como odio al universo...

¡Los transformer ya están aquí!

2008-07-08T12:17:00.003+02:00

Me da que dentro de no muchas navidades alguno se pide uno de estos trastos

¡ Qué ilusión !, me encanta comprobar que existe gente que trabaja por el bien de la humanidad, que pone todo su esfuerzo en facilitar la vida a todas aquellas personas necesitadas... mirad este vídeo, el robot que nos trae cervezas de la nevera cada vez está mas cerca... ¡ y siguiente paso será que encienda la tele !

Artículo - Aprendiendo a manejar objetos

2008-07-08T11:43:00.002+02:00

En el último artículo publicado hasta la fecha del Cog, se describen los resultados obtenidos tras 'enseñar' a dos robots a manejar objetos. Han usado dos tipos distintos, un BabyBot y un Cog (el de la foto).

Con el primero, se ha tomado un objeto y se ha movido dentro de su campo de visión, mas tarde, el robot ha sido capaz de imitar este movimiento y desplazar un objeto de similares características.

El segundo experimento ha sido mas complejo gracias a las características del Cog, este ha sido capaz de distinguir cuatro objetos distintos, y mimetizar los movimientos aprendidos dependiendo del objeto. Lo que dicho con palabras distintas, sonaría a que el robot ha sido capaz de 'comprender' que objeto tenía delante y donde debía colocarlo

Si os gustan este tipo de cosas echadle un vistazo al artículo entero, es cortito, apenas 5 páginas.

LOST - Método de exploración de caminos

2008-07-07T17:56:00.004+02:00

Hace poco he leído un artículo que trata sobre la exploración de caminos por medio de un grupo de robots. Maja Matarić (la que tiene pelo) se inspira en las colmenas de abejas y hormigas para crear un modelo no centralizado que sea capaz de encontrar rutas eficaces en un entorno desconocido.

Para encontrar dichas rutas, emplea la información recolectada por cada miembro del grupo (hormiga) sobre el entorno que lo rodea, compartiendo esta información con el resto de robots. Esta información (migas) se combina con la poseída por cada robot para confeccionar un mapa del entorno al completo en el que se encuentra la población. Las 'migas' intercambiadas por los distintos miembros se componen (a groso modo) de lugares (coordenadas relativas) y tiempos de desplazamiento entre estos.

Como puede verse en los experimentos y en las conclusiones, los métodos de autolocalización son extremadamente importantes, ya que el error acumulado de estos influye directamente en el resultado final. Por un lado la odometría ofrece una amplia independencia del medio, pero el error acumulado es demasiado importante. La localización por GPS otorga un mínimo error, pero no en todas partes podemos disponer de esta tecnología.

Aunque no pudo comprobarlo directamente, las simulaciones que realizó demostraron que a mayor número de miembros, mejores resultados se obtienen (con rutas mas óptimas), aunque el tráfico empleado en los mensajes aumenta de forma exponencial y puede resultar un serio problema

Otros asuntos que deja para futuras investigaciones son cosas como los problemas que tendrían las hormigas al intentar pasar todas a la vez por un lugar estrecho, o tener un lugar de referencia detrás de un obstáculo demasiado grande.

Aplicación para el patito

2008-06-26T20:06:00.004+02:00

La anterior entrada hacía referencia a una interfaz gráfica para ver de forma mas bonita el robot que hará de guía. Ahora le ha tocado el turno al otro robot. Esta aplicación es muy similar a la anterior, con mínimos cambios:

Se ha eliminado la velocidad del robot, pues esta ya no es controlable, será el propio robot quien establezca la velocidad a la que debe moverse.

Se ha incluido una imagen que representa un rectángulo con los cuatro puntos 'vistos' por la cámara de infrarrojos del wiimote. Nos da una idea de que está viendo el robot a tiempo real. Él se basará en estos puntos para determinar la distancia con su 'mamapato' y la dirección a tomar.

Como tonterías añadidas, se puede cambiar los colores y la resolución del visor

Otra aplicación mas

2008-06-24T10:16:00.003+02:00

Después de varias intentonas, al fin he conseguido una aplicación gráfica útil para mis propósitos. En esta ocasión es un interfaz gráfico para controlar el robot de cabeza, o "Mama Pato". Una vez han sido conectado Wiimote y Brick por medio de la cruceta del mando puede controlarse el robot como si de un coche teledirigido se tratase.

No tiene nada especial, activar algunas 'pijotadas' para el mando como leds o vibración, controlar la velocidad de movimiento del robot...

Desde Barna con amor

2008-06-13T11:53:00.002+02:00

Hace tiempo que no pongo un vídeo de robots chorras, así que aquí va. ¿Qué objetivo puede haber en la vida mejor que el de buscar objetos para hacer música?

El vídeo me lo ha enviado Pepe, que "es una gran persona y mejor ser humano". ¡Gracias amigo!

La distancia entre dos puntos

2008-06-11T17:22:00.005+02:00

Pasamos a sacarle partido a la cámara de infrarrojos del wiimote. Para empezar vamos a calcular la distancia (en pixeles) entre dos puntos, mas adelante usaremos esta información para saber lo lejos (o cerca) que nos encontramos de un objeto que disponga de dos emisores infrarrojos que están separados el uno del otro por una distancia conocida.

El primer paso, entonces, se trata en conocer la distancia entre estos dos puntos. Para verlo todo de formas mas gráfica he utilizado la extensión pygame y he tomado unas 'fotos' para contar los pasos seguidos.

Partimos de un momento 't', en el que leemos dos puntos en la cámara del mando, estos dos puntos, como indica la figura 1, son A y B

figura 1

De cada punto conocemos sus coordenadas, lo cual nos facilita enormemente el trabajo. A estas coordenadas las llamaremos (Xa, Ya) (Xb, Yb). Como los ejes X y Y son perpendiculares, trazamos dichos ejes atravesando nuestros puntos, obteniendo el resultado de la figura 2

figura 2

A la intersección de ambos ejes la denotaremos como C, con un poco de imaginación puede verse que la recta AB es la hipotenusa formada por los vértices ABC (figura 3).

figura 3

Recordando uno de los teoremas de Pitágoras sabemos que h2 = c2 + C2. (el dos indica cuadrado, a falta de Latex...)

Sólo nos faltaría saber las coordenadas de C, o bien la longitud de los lados AC y BC, algo que tenemos que extraer de la información disponible. Para conocer la distancia AC basta con restar la coordenada Xb a Xa, o siendo mas precisos, el valor absoluto de esta diferencia.

BC lo obtendremos por el mismo procedimiento, y será igual al valor absoluto de la diferencia de Ya e Yb

Ya disponemos de la distancia, en píxeles, de ambos puntos. El siguiente paso es utilizar esta información para saber la distancia a la que nos encontramos del objeto que tiene los emisores

NOTA: Me habría encantado utilizar Latex para las fórmulas, pero la solución que me pasó Javi parece no funcionar en linux

El tiro por la culata

2008-06-07T18:22:00.003+02:00

Al cabo de un rato terminé encontrando el motivo por el que recibía esos valores negativos tan extraños. Aunque todo indicaba lo contrario el valor devuelto por la instrucción xhat[-1] es correcto para el vector xhat (que raro que yo me equivoque).

Al principio pensé que el problema radicaba en que yo solicitaba el valor del vector cuando este estaba siendo tratado por el filtro. Me explico: actualmente tengo dos clases, una llamada Kalman encargada de filtrar la información cuando se agreguen valores leídos por el mando, y la clase Wiimote que entre otras muchas cosas trata las "interrupciones" del mando, entregándosela al objeto kalman para que la filtre, un momento después se solicita el último dato del vector ya filtrado para así calcular velocidad y espacio en tiempo real.

Para evitar esto (un error de programación por mi parte) creé un vector nuevo, copia del anterior, que sólo se actualiza cuando toda la información ha sido filtrada, de forma que siempre devolverá un valor filtrado (aunque sea uno que ya ha sido entregado). Pero esto tampoco funciona, los valores extraños siguen apareciendo, y ahora mismo no se como resolverlo.

Calcularé velocidad y espacio una vez terminado un movimiento, no es igual de 'bonito' pero creo que es la última baza que me queda para utilizar el mando (al menos con el enfoque actual)

El que la sigue la persigue

2008-06-04T12:33:00.005+02:00

Ayer por fin encontré donde está el fallo, el por qué no funciona, la línea que estropea todo... pero lo mas triste es que no se como repararlo.

El problema está, y no está, en el filtro Kalman. La implementación que tengo de él funciona perfectamente. Este algoritmo crea un array perteneciente al paquete numpy (que proporciona arrays mucho mas útiles que los de python estandar) para almacenar los datos filtrados. Es de este array (al que llamo xhat) del que extraigo los datos para calcular la velocidad y el espacio.

Ahora un breve repaso al manejo de arrays en python

Creamos una variable 'vector' que contiene tres números, en este caso enteros

>>> vector = numpy.array([1, 2, 3])

Si queremos acceder a la primera posción (contando desde 0) sólo tenemos que ejecutar

>>> vector[0]
1

Para un vector de números 'flotantes'

>>> vector = numpy.array([1.1, 2.1, 3.1])
>>> vector[-1]
3.1

Con el índice negativo comenzamos a contar desde el final

Por defecto, el paquete numpy crea arrays de tipo float64 que permite almacenar números mas grandes, aunque esto es algo que puede modificarse en el momento de crear el array.

El problema viene ahora, el algoritmo rellena el array xhat, de tal forma que si quisiera obtener el último elemento de este para hacer mis cálculos, ejecutaría una instrucción tan sencilla como esta

>>> xhat[-1]

y al menos yo esperaba obtener un número 'flotante', pero... no. Por algo que no entiendo, que parece ser contra natura, obtengo otro número. Si, otro número. No es el número xhat[-1] redondeado, no. Ni siquiera parecido, es, simplemente, otro número. Que en la mayoría de los casos viene a ser algo aproximado de -1.04... que provoca que la velocidad descienda por debajo del 0

¿Por qué?

Vaya usted a saber, yo llevo desde ayer preguntando a google y no me dice nada coherente. Lo bueno es que he encontrado el problema, lo malo, que roza lo absurdo.

Menos mal que al ser tan cabezota terminaré encontrando la solución, y seguro que es una tontería

Pruebas, pruebas, pruebas...

2008-06-03T17:16:00.002+02:00

Desde la última entrada he realizado pruebas con el código actual. Los resultados, para ser francos, no son muy esperanzadores. En ocasiones la medición es de una exactitud asombrosa, y en otras, son un desastre. No me refiero a que el error cometido sea de 5 cm, ni siquiera 10. Muchos experimentos arrojan medidas negativas de dos decenas de centímetros, y eso no es muy normal.

He revisado ya varias veces el ćodigo referente a la cinemática, lo he contrastado con libros de física y parece ser todo correcto. El filtro de kalman parece funcionar correctamente, ya que la aproximación gráfica que obtengo de la aceleración se ajusta increíblemente bien a la realidad. Y sin embargo, en muchos experimentos termino obteniendo una velocidad negativa y por consiguiente un retroceso en el espacio. Aún dejando varios segundos el mando en reposo, sin que exista mas fuerza que la gravedad actuando sobre él (fuerza que para mi experimento no es significativa)

He encontrado un artículo bastante técnico sobre este asunto (aplicado también al wiimote) que he releído varias veces. Es posible que mi tosco inglés no me permita sacar todo el jugo al texto, pero creo que lo esencial si lo aplico en mi algoritmo.

De momento, sigo con pruebas, pruebas y pruebas...

De pruebas en (el) Ibiza

2008-05-27T13:54:00.004+02:00

Ante los esperanzadores resultados de ayer, esta mañana me he ido a "darle cera" al acelerómetro. El experimento ha sido sencillo, acelerar de 0 km/h hasta 80 km/h, y frenar de nuevo hasta detener el coche. Han sido dos pruebas, y la distancia recorrida de aproximadamente 200mts (medido con el odómetro del coche y teniendo en cuenta que mi coche mide a una escala de 100 metros)

Test 1

Test 2

Con lo que me ha costado llegar a programar esto espero no estar demasiado tiempo con la calibración del filtro. Seguiré haciendo pruebas a bajas y altas velocidades hasta que los resultados sean algo coherentes.

Comienzan a salir las cosas

2008-05-26T15:31:00.009+02:00

Bien, después de muchas horas de desesperación creo estar cerca de poder usar el wiimote para conocer la distancia recorrida por el robot, o en otras palabras, tener un sistema de odometría fiable.

Primero unos repasos de la física del instituto. Si disponemos de un objeto que se desplaza a lo largo del espacio (s) y medimos el tiempo (t)que invierte en este desplazamiento, podemos obtener su velocidad (v), con algo tan simple como derivar el espacio respecto del tiempo

v = s / t

Donde s corresponde al incremento del espacio (s1 - s0) y t al incremento del tiempo (t1 - t0). Bien, si derivamos de nuevo la velocidad respecto al tiempo, podremos obtener la aceleración del objeto. Siendo esta aceleración un movimiento conocido por todos como "movimiento uniformemente acelerado".

Para recorrer el camino al contrario, simplemente tenemos que calcular las integrales de estos valores respecto del tiempo, es decir, conociendo la aceleración (a):

v = v0 + a(t - t0)

y el espacio:

s = s0 + v0(t - t0) + 1/2 (a (t - t0))

Ahora el experimento, en un movimiento acotado de 30 cm desplazamos el mando por la horizontal desde una v0 = 0 hasta una velocidad final también 0, los resultados obtenidos son los siguientes:

La aceleración tiene errores de lectura

La velocidad desciende por debajo de cero (como si el objeto invirtiese la dirección del movimiento)

Y el espacio retrocede a lo largo del tiempo aproximándose a cero

Bien, con esto no voy a ninguna parte, así que aplicando el filtro de kalman a la aceleración, los resultados obtenidos son los siguientes:

La aceleración se ha suavizado, ahora se ajusta mas a la realidad

La velocidad no ha tenido mejoras, seguimos cayendo por debajo de cero

Y como era de esperar, el espacio "retrocede"

Así que utilizamos de nuevo el filtro de kalman, pero esta vez aplicado primero a la aceleración y luego a la velocidad. Los resultados son los siguientes:

La aceleración filtrada, obtiene una gráfica mas real

La velocidad, esta vez si desciende de forma normalizada, sin llegar a 0, pero sin tomar valores negativos

Ahora si, el espacio aumenta, pero sobrepasa los 30cm del experimento hasta el doble

Y la última prueba, filtrando el espacio con los datos a su vez filtrados de velocidad y aceleración. Las gráficas correspondientes a estas dos últimas no varían

Pero retrocedemos en los resultados esperados para el espacio

Conclusiones: El filtro de kalman resulta tremendamente útil para obtener una información mas cercana a la realidad que la obtenida por medio de las mediciones, ya que nos permite eliminar el ruido. Sin embargo, sólo en una de las pruebas el resultado espacial ha estado cercano a los 30cm del experimento (con un error de 1cm). Así que algo he dejado en el aire, tal vez sean los ajustes del filtro.

¿alguna sugerencia?

Wiimote GUI

2008-05-23T10:55:00.004+02:00

Como ayer era incapaz de mirar el mando de la wii sin sentir deseos de matar a Mario decidí seguir trabajando con ello, pero yendo por la tangente. Así que programé en GTK una interfaz gráfica para ver las lecturas del mando.

La cosa es bastante simple, y no tiene otra misión que pintar en una ventana lo que hasta ahora he visto por consola, pero haciendo las pruebas he visto que un problema que ya apareció se intensifica un poco. Sufro un desbordamiento en la pila de mensajes enviados por el mando, ¿soy lento recogiendo los mensajes?, ¿lento procesando?, ¿será la biblioteca que uso de python?

El caso es que un programa similar creado por los chicos de cwiid no adolece de este desbordamiento y no pone al portatil al borde de la levitación, por lo que me inclino en pensar que es python el culpable (¡no voy a ser yo!)

Aceleraciones y desaceleraciones

2008-05-21T16:45:00.005+02:00

Mientras continúo intentando conocer el espacio recorrido por medio de las aceleraciones medidas por el mando de la wii, he encontrado un proyecto que ya intentó esto mismo, pero en su caso "sujetando" el mando a la rueda del robot para hallar el espacio por medio de las rotaciones que daba el mando.

La dirección del proyecto es esta http://wiibotics.blogspot.com/

y su conclusión... esta otra

Conclusions

My original inspiration for working with the wiimote turned out to be a somewhat-solved problem, since many cursor-control scripts have been written to turn the wiimote into a mouse. I had hoped to make it possible to use such control without being bound to a pair of IR hotspots, but I suspect that the wiimote accelerometer alone will never be accurate and sensitive enough to make this feasible.

Although I had high hopes for the Wiimote being realized as a fully-fledged robot, in half a semester, I was only able to bring it up to speed as an alternative solution to a common problem in robotics: measuring wheel rotation. Still, I hope that this will be its proverbial foot in the door; a stepping stone to more widespread and varied uses. Sensing the grade of the road under a car-like vehicle is as simple as mounting a wiimote parallel to the ground and reading the pitch. With that same wiimote we could do bump-sensing by watching for the force along the long axis of the wiimote to rise above a certain threshhold. I have no doubt that many more uses could be found.

Espero que todo el trabajo que llevo llegue a mejor puerto y no termine escribiendo unas conclusiones similares

Una de vídeos tontos

2008-04-17T18:23:00.003+02:00

Hace tiempo que no pongo ningún vídeo curioso de robots, espero que no lo hayáis echado en falta.

El primero de ellos es un robot que escucha los toques del tambor e intenta imitarlos, es increíble de lo que es capaz el ser humano cuando se aburre...

¿Recordáis el vídeo del cuadrúpedo que os puse hace un tiempo?, pues os dejo otro vídeo de este impresionante modelo.

Repito, es increíble lo que llega a realizar el humano cuando se aburre... realmente increíble...

Y por último un vídeo que poco o nada tiene que ver con el mundo de los robots y con el TFC, pero a fin de cuentas esta entrada está un poco fuera de lugar, así que tampoco desentonará mucho. Va dedicado a toda esa estupenda gente que ha pasado casi media vida delante de una preciosa consola negra y ha programado en vi ;) (y que seguro siguen haciéndolo)

Aceleraciones y ajustes

2008-04-17T18:00:00.005+02:00

Llevo ya muchos días enfrascado trabajando con el acelerómetro del mando de la wii, este dispone de un acelerómetro ADXL330 para medir la fuerza que actúa sobre el mando en los tres ejes. De momento sólo trabajo con la información del eje Y, ya que el mando estará colocado de forma horizontal con los mandos hacia arriba y la cámara de infrarrojos hacia delante.

Con esta información no pretendo determinar la velocidad a la cual se desplaza el robot, sino la distancia que avanza. Si recordamos un poco de la física que estudiamos en el instituto (ha llovido mucho desde entonces...) derivando la distancia recorrido respecto del tiempo obtenemos la velocidad, y derivando de nuevo esta llegamos a la aceleración. Deshaciendo este camino llegamos de nuevo a la distancia.

Las pruebas realizadas no me han dejado muy contento, los datos obtenidos de la realidad distan bastante de los valores esperados, por lo que Javi me sugirió que utilizase el filtro de Kalman para suavizar el impacto de estos. Este filtro utiliza la información de la medición para intentar 'adivinar' con la mayor probabilidad posible el valor que debería tener el siguiente dato (en relación al que ha tenido). Si queréis ahondar un poco más, os dejo el enlace de la socorrida wikipedia.

Una vez implementado este filtro en python he pasado a realizar nuevas mediciones y he podido ver como los datos filtrados se ajustan más a la realidad que los propios datos leídos del mundo real.

Ahora sólo queda saber si con la aceleración filtrada puedo obtener una medida del espacio coherente, que será a lo que dedique los próximos experimentos.

Os dejo un gráfico que representa la aceleración del mando en su eje Y en un tiempo de aproximadamente dos segundos.

Consejos para Lego Digital Design

2008-04-05T17:30:00.003+02:00

Después de jugar un buen rato con este software, he recopilado una serie de consejos que de haberlos sabido me habrían ahorrado tiempo y algún que otro quebradero de cabeza, así que los publico por si en el futuro pueden venirle bien a alguna persona (incluido yo mismo, que tengo una memoria...)

Siempre que tengas una construcción que te gustaría conservar en LDD dedica unos minutos a comprobar que no tienes piezas forzadas

Utiliza todos los recursos que te provee el software, por ejemplo, para piezas que tienes montadas de forma simétrica es más sencillo clonar la que ya tienes puesta que coger una nueva y girarla

Las piezas pueden girarse con total libertad, pero requiere un poco de astucia. Si deseas colocar una pieza con una inclinación de 45º, coloca un conector y utiliza la herramienta de giro (Hinge Tool) para hacerla rotar sobre este conector. Necesitarás un poco de pulso para obtener la inclinación deseada, ya que el programa no te da información sobre la nueva posición

No te desesperes si una pieza no quiere encajar en su lugar correspondiente, prueba a girar la cámara para encontrar un mejor ángulo de trabajo

La mejor forma para trabajar que he encontrado es manejar la cámara (giros y zoom) con el ratón y los giros de pieza y atajos de teclado con la otra mano

Es posible que utilices piezas que no vienen en el inventario, en ese caso tendrás que echarle imaginación para procurar encontrar un sustituto a ese elemento. Lamentablemente la mayoría de las piezas Technic no vienen incluidas, esperemos que en el futuro esto cambie

No olvides colocar los cables si trabajas con el set de Mindstorm, no es vital, pero así tu modelo estará completo

¡Suerte!

Lego Digital Design

2008-04-04T01:04:00.005+02:00

Hace tiempo descargué esta aplicación de Lego y hasta hoy no he recordado su existencia. Como se intuye por su nombre, nos permite desarrollar un diseño digital de nuestras construcciones, funciona a modo de CAD y es muy útil para gente tan despistada como yo que nunca sabe como reconstruir los modelos.

Los usuarios de MAC tienen su propia versión, y para los rebeldes insurrectos que nos negamos a utilizar sistemas propietarios, pues siempre nos quedará nuestro querido wine :D

Buscando en youtube

2008-04-03T23:52:00.002+02:00

Casi sin quererlo he encontrado estos dos vídeos en Youtube. Al primero de ellos he llegado a través de la web de "robótica recreativa y educativa" y es un ejemplo del uso del sensor gyro en el NXT. Creo que este vídeo le puede venir bien a cualquier persona que quiera construir un péndulo invertido, pues si no me equivoco la construcción de un artilugio así debe basarse en el mismo principio que utiliza este otro péndulo para detectar la velocidad y posición. Por cierto, el robot lo ha desarrollado hitechnic

El otro vídeo es de un robot "busca-caminos", "evita objetos" o como queramos llamarlo, me ha llamado la atención las ruedas que utiliza (por llamarlo de alguna forma), si no me equivoco están tomadas de la serie Exoforce de Lego. El robot es de grandes dimensiones, y gira sobre su propio eje gracias al enorme tamaño de las ruedas, ya que cada par de ruedas puede ser controladas por un motor sin utilizar un número excesivo de ruedas dentadas. ¿Y para que sirve esto?, por ejemplo, para construir un robot grande capaz de incorporar muchos sensores o material vario. Si queremos dotarle de dirección al vehículo esta puede resultar poco útil en terreno adverso y lo mas eficiente son los giros sobre el propio eje, vamos, lo que hacen los tanques

El robot que era tímido

2008-04-02T18:05:00.003+02:00

Para que el wiimote y el NXT empiecen a trabajar juntos, he construido un robot muy sencillo que acopla el mando de la wii. El algoritmo de trabajo es muy sencillo a falta de unas cuantas pruebas mas, al recibir una señal de infrarrojos el robot gira 180 grados para "huir" de la señal.

En las pruebas se han producido giros superiores a 180 grados, esto ocurre por que se detectan varios mensajes que indican la presencia de una fuente emisora, por lo que son varios semi-giros los que se producen.

Como viene siendo normal, he utilizado python junto con nxt-python y cwiid, todo servido en una bonita máquina derivada del modelo básico que viene con la caja de lego.

Los ojos de Benito

2008-04-02T12:07:00.005+02:00

Estoy haciendo pruebas con la cámara de infrarrojos que incorpora el wiimote, esta cámara nos proporciona una resolución de 1024x768 con una profundidad de color de 1 bit y es capaz de ver hasta cuatro puntos de forma simultánea.

Con la librería pygame de python he escrito un pequeño programa para "ver" tal y como lo hará el robot con la cámara del mando, y este es el resultado

La prueba ha sido hecha con el mando de la minicadena, emitiendo de forma continua (atendiendo a la repetición de la tecla back-track) en línea horizontal con el mando. La verdad, ahora mismo no se como interpretarlo, debo darle aún un par de vueltas para saber como ver con estos ojos nuevos, seguiré informando ;)

Johnny5

2008-04-01T14:02:00.002+02:00

Ayer recordé una web que encontré al poco de tener el NXT, y es que cualquiera que haya visto el sensor de ultrasonidos lo habrá asociado inmediatamente con la película "cortocircuito". Pues bien, os paso una página en la que muestran al robot construido (no he encontrado las instrucciones) y un bonito vídeo del Johnny5 en acción

que conste que con esto no quiero influir en las votaciones de la encuesta, que ya sabéis todos que para mi el mejor siempre será Mazinger Z (y no me refiero al Papa)

De infrarrojos y pantallas de leds

2008-03-27T21:18:00.002+01:00

Seguimos jugando con el mando de la wii. Buscando la mejor forma de aprovechar sus características infrarrojas he dado con el proyecto de Johnny Chung Lee, en él comenta como ha utilizado las capacidades del mando, y me ha parecido muy interesante.

Usa una pantalla de aproximadamente 100 leds emisores de infrarrojo (como los que llevan incorporados las cámaras de visión nocturna) con una batería de 9v (por que si no dudo que funcione). Dentro de esta pantalla aloja el mando y utiliza un material reflectante para que el mando "vea" las señales infrarrojas. Creo que un vídeo ilustrará mucho mejor lo que acabo de contar

Y mi idea es utilizar un modelo similar. Montar una placa de dimensiones apropiadas alrededor del mando, y todo ello acoplado en el robot. Como es lógico, los objetos deberán estar forrados con un material reflectante (como el papel aluminio) y de esta forma el robot en su conjunto podrá identificar el obstáculo y evitarlo

He echo unas pruebas caseras con el mando de la tele y todo ha salido como se esperaba (nunca dejaré de asombrarme cuando las cosas me funcionan a la primera). Ahora probare a dibujar en la pantalla la fuente emisora, algo parecido a lo que hace John en el vídeo. Ya os contaré

Haciendo las pruebas me ha sucedido algo que me ha desconcertado un poco y seguro que alguno de vosotros sabe por qué sucede. Sobre "el taller" tengo un flexo con una bombilla corriente (no es de bajo consumo) y el mando recogía el flexo como fuente emisora al ser reflejada la luz en el papel aluminio. Imagino que sucede por que la luz se descompone en el papel, pero si alguno de vosotros lo sabe con certeza le agradeceré que me lo aclare. He probado con linternas y otras lámparas pero no hubo éxito, sólo con el flexo.

Documentación pyton-cwiid

2008-03-27T12:20:00.006+01:00

A raíz de las notas que he tomado y las pruebas realizadas he escrito una breve documentación de la biblioteca cwiid para python. No está completa y seguramente contenga errores y equivocaciones, por lo que si veis alguna cosa rara o tenéis alguna sugerencia no dudéis en comentarlo.

(revisión 1.0)

cwiid.__doc__
CWiid Wiimote Interface

cwiid.__file__
/var/lib/python-support/python2.5/cwiid.so

cwiid.__name__
cwiid

Constantes

BATTERY_MAX
Indica el nivel máximo de batería, se utiliza para determinar el nivel actual de batería

BTN_UP
BTN_DOWN
BTN_LEFT
BTN_RIGHT
BTN_A
BTN_B
BTN_1
BTN_2
BTN_MINUS
BTN_PLUS
BTN_HOME
Botones del Wiimote

CLASSIC_BTN_A
CLASSIC_BTN_B
CLASSIC_BTN_DOWN
CLASSIC_BTN_HOME
CLASSIC_BTN_L
CLASSIC_BTN_LEFT
CLASSIC_BTN_MINUS
CLASSIC_BTN_PLUS
CLASSIC_BTN_R
CLASSIC_BTN_RIGHT
CLASSIC_BTN_UP
CLASSIC_BTN_X
CLASSIC_BTN_Y
CLASSIC_BTN_ZL
CLASSIC_BTN_ZR
CLASSIC_LR_MAX
CLASSIC_L_STICK_MAX
CLASSIC_R_STICK_MAX
Botones del mando clásico

CMD_LED
CMD_RPT_HOME
CMD_RUMBLE
CMD_STATUS
En la biblioteca de Python no tienen aplicación

ERROR_COMM
ERROR_DISCONNECT
Tipos de error

EXT_NONE
EXT_NUNCHUK
EXT_CLASSIC
EXT_UNKNOWN
Las distintas extensiones que soporta el mando

FLAG_CONTINUOUS
Habilita informes continuos del Wiimote

FLAG_MESG_IFC
Habilita el interfaz basado en mensajes (a través de callback)

FLAG_NONBLOCK
Provoca que get_mesg() se falle en lugar de bloquearse esperando un mensaje si la cola está vacia

FLAG_REPEAT_BTN
Se envía un mensaje por cada botón pulsado, aunque este no haya cambiado de estado

IR_SRC_COUNT
IR_X_MAX
IR_Y_MAX
Definiciones para el IR

LED1_ON
LED2_ON
LED3_ON
LED4_ON
Valores para encender/apagar los led

MAX_READ_LEN
Longitus máxima que puede leerse

MESG_ACC
MESG_BTN
MESG_CLASSIC
MESG_ERROR
MESG_IR
MESG_NUNCHUK
MESG_STATUS
MESG_UNKNOWN
Tipos de mensaje recibidos

NUNCHUK_BTN_C
NUNCHUK_BTN_Z
Botones del Nunchuk

RPT_ACC
RPT_BTN
RPT_CLASSIC
RPT_EXT
RPT_IR
RPT_NUNCHUK
RPT_STATUS
Establecen los distintos tipos de informe (reporting mode) del wiimote. Cada uno determina que dispositivo está activo y que datos deben ser enviados al host. Cada flag especifica un bit, por lo que deben establecerse por medio de funciones OR

RW_DECODE
RW_EEPROM
RW_REG
Flags para los registros del wiimote

X
Y
Z
Identificadores de los distintos ejes del wiimote

Métodos

Wiimote(bt_addrs)
Parámetros
bt_addrs: Dirección Bluetooth del wiimote

Descripción
Conecta con el Wiimote especificado o con el primero que encuentre si no se especifica mando

Valor de retorno
Un objeto Wiimote si la conexión ha tenido éxito

Class Wiimote()
Una vez creado un objeto de tipo Wiimote a través de cwiid.Wiimote() disponemos de los siguientes atributos y métodos para esta clase

Atributos
state
Diccionario con el estado actual del mando

mesg_callback
Función para tratar los mensajes enviados por el wiimote. Una vez se pone a funcionar el mando en un modo RPT_XXX este envía mensajes cada vez que sucede un evento. Estos mensajes son tratados con la función indicada en este atributo (La función debe haber sido declarada anteriormente)

rpt_mode
Modo de informes del mando: RPT_ACC, RPT_BTN, RPT_CLASSIC, RPT_IR, RPT_EXT, RPT_NUNCHUK, RPT_STATUS

led
Atributo para activar/desactivar los led
Ej: wiimote.led = cwiid.LED1_ON
wiimote.led = not cwiid.LED1_ON

rumble
Atributo para activar/desactivar la vibración
Ej: wiimote.rumble = 1

Métodos

close()
Descripción
Cierra la conexión con un objeto Wiimote

enable(flags)
Parámetros
FLAG_CONTINUOUS, FLAG_MESG_IFC, FLAG_NONBLOCK, FLAG_REPEAT_BTN

Descripción
Habilita los flags indicados

disable(flags)
Parámetros
FLAG_CONTINUOUS, FLAG_MESG_IFC, FLAG_NONBLOCK, FLAG_REPEAT_BTN

Descripción
Deshabilita los flags indicados

get_acc_cal(extension)
Parámetros
EXT_NONE, EXT_NUNCHUK, EXT_CLASSIC, EXT_UNKNOWN

Descripción
Devuelve una tupla ( (X,Y,Z) , (X,Y,Z) ) con la información sobre la calibración del acelerómetro

Valor de retorno
Tupla ( (X,Y,Z) , (X,Y,Z) )

get_mesg()
Descripción
Devuelve un mensaje de la cola, estos mensajes se recuperan por medio de "callback" o de esta función

Valor de retorno
Mensaje mas antiguo de la cola

read(flags, offset, lenght)
Parámetros
flags: RW_EEPROM, RW_REG, RW_DECODE
offset: Dirección de inicio
lenght: Longitud

Descripción
Lee datos desde el Wiimote, utiliza los flags RW_EEPROM, RW_REG (mutuamente exclusivos)para leer desde la memoria EEPROM o desde el registro. El flag RW_DECODE realiza cualquier decodificación de los datos leídos si es necesario.

Valor de retorno
Los datos leídos

write(flags, offset, buffer)
Parámetros
flags: RW_EEPROM, RW_REG, RW_DECODE
offset: Dirección de inicio
buffer: Información a escribir

Descripción
Escribe datos en el Wiimote, utiliza los flags RW_EEPROM, RW_REG (mutuamente exclusivos)para leer desde la memoria EEPROM o desde el registro. El flag RW_DECODE es ignorado.

request_status()
??

Referencia
http://abstrakraft.org/cwiid/wiki/libcwiid

Canal de Youtube

2008-03-27T10:30:00.003+01:00

Hasta ahora he publicado los vídeos a través de Google Video, pero no estoy muy contento con el servicio, ya que algunos vídeos tardan mucho en ser procesados y en ser servidos, así que he abierto un canal en youtube, ya veremos como funciona

http://es.youtube.com/user/mmartinortiz

Mi coche de carreras

2008-03-26T19:34:00.005+01:00

Tras la desesperación de anoche y la angustia de esta mañana he ido a pasar frío y correr durante un buen rato para aclarar las ideas. Con mucha paciencia y la ayuda de IDLE (el enésimo IDE para python que he probado) he escrito una breve documentación para cwiid. Tengo intención de subirla, por si le resulta útil a alguien.

Gracias a la gente de CRySOL y a la demo escrita en python que viene junto al paquete de cwiid he escrito un pequeño programa para conducir mi propio coche teledirigido utilizando la cruceta del mando. Manejarlo con golpes del mando no es mucho mas complicado, habría que manejar unos eventos en lugar de los otros y los vídeos que he visto con ese manejo no son tan elegantes. Os adjunto un par de vídeos para que veáis el resultado.

En este vídeo se ve la cruceta del mando

Y esta es una foto con parte del taller que tengo montado (no viene a cuento, lo se)

Jugando con la Wii

2008-03-25T23:20:00.005+01:00

¡Al fin tengo un mando para la Wii!. después de mucho corretear por Talavera he encontrado una tienda en la que si tenían mandos (de hecho tenían dos mandos, ahora sólo uno). Lleno de alegría e ilusión he puesto camino a casa, con mucho mimo he sacado el mando y le he puesto las pilas (en la caja pone que es un mando, pero a mi me da que esto es un vibrador)

Lo primero, ver si funciona, y como no tengo una Wii, pues a conformarme con el programa de prueba que trae el driver que estoy usando, cwiid (odio profundamente a las personas que desarrollan una API completa y no escriben una puñetera línea de documentación), lo ejecuto y "me llena de orgullo y satisfacción" ver como reconoce el mando a la primera, los botoncitos lucen, el acelerómetro va bien y el infrarrojos... bueno, el infrarrojos no funciona por que no tengo un emisor de infrarrojos, pero a esto ya le encontraremos solución mas adelante.

Ahora que se que funciona el mando, vamos a buscar la biblioteca para python que tengo ganas de caharrear con él. Después de ir y venir, de apt-cachear y pedir ayuda a San Google, encuentro el paquete para ubuntu (python-cwiid) que sólo está disponible para la versión Hardy de Ubuntu, así que toca actualizar algún que otro paquete para poder instalarla.

Bien, ya tenemos la biblioteca, ¡vamos a jugar!, después de fijarme en el código que viene escrito en python para comprobar que el mando funciona, escribo un pequeño script para recuperar la información de acelerómetro. Recuperar... la recupero. Antes dije que odiaba mucho a los desarrolladores que no escriben una jodida (digo jodida por no decir puta, que suena muy mal) línea de documentación para aliviar los sufrimientos del prójimo, pues bien, ahora los odio mucho mas.

Algo que no he contado antes, mas que nada por que no viene a cuento, es que empecé escribiendo código utilizando geany (bueno y ligero), pero le falta completar el código, algo que me resulta enormemente útil cuando no hay documentación alguna (se que los hombres y mujeres de verdad no utilizan estas mariconadas, que con vi es suficiente, pero es que yo no soy ni un hombre ni una mujer de verdad). Luego me pasé a Editra, que mola mazo, pero... le faltan muchas cosas que si ofrece Geany, así que sigo buscando y ahora estoy probando openkomodo, que es muy pesado y me recuerda a mi querido NetBeans. Todo esto, que no tiene mayor importancia, viene por que llevo cerca de dos horas dando vueltas, buscando un método o función que me permita recuperar valores del mando de la wii sin tener que leerme todo el código

Y hoy, hasta aquí. Noto que la neurona patina un poco y creo que será mejor mirar un rato al infinito para que descanse. Mañana volveré a la carga

¡Cuidado con el perro!

2008-03-24T14:15:00.003+01:00

Leyendo las cosas de barrapunto he encontrado este vídeo de un cuadrúpedo desarrollado por Boston Dynamics. Me encanta como recupera el equilibrio después de recibir el golpe.

El valor de la sencillez

2008-03-16T13:23:00.003+01:00

La semana pasada estuve hablando con Javi, que me pasó un par de artículos para salir de mi atolladero de diseño. A parte de esto, decidimos jugar con un robot que siguiese un haz de luz (una linterna, el móvil...).

Entre artículo y artículo, se me ocurrió una idea genial. Construir una cabeza giratoria que buscase el haz de luz a lo largo de giros completos de 360 grados en caso de perderlo, para sincronizar esta cabeza con las ruedas podría utilizarse un par de mandos de la wii, pero este problema se afrontaría mas adelante. De momento mi mente había tenido una idea genial y había que construirla.

Manos a la obra, un par de horas el sábado y otras tantas el domingo para construir una preciosa cabeza giratoria en pos de la luz. Henchido de orgullo pruebo mi creación, ¡fabuloso!. Las ruedas dentadas danzan elegantemente con un suave ronroneo de fondo, la mecánica es maravillosa, el movimiento se transforma a lo largo del espacio para que el sensor de luz explore su entorno.

Y entonces... me doy cuenta de mi gran error, un error catastrófico, que se lleva al garete mi obra. Como no voy a desarmar tan elegante creación de la mecánica sin dar testimonio de ella, os dejo un vídeo de su funcionamiento para que veáis "la enorme cagada" de este soleado fin de semana.

Y desde un poco mas cerca...

¿Lo veis?, no he tenido en cuenta que el sensor de luz hay que conectarlo, y para eso hay un cable que está anclado en la base del robot, estática en relación a la cabeza, así que el cable se retorcería hasta impedir el movimiento de la cabeza y con ello su funcionalidad.

La solución es sencilla, que el sensor de luz sea estático con relación al cuerpo, y que sea todo el cuerpo el que se mueva para encontrar el haz de luz perdido. Esta solución no mola tanto como la cabeza giratoria, pero es mas sencilla de montar, de implementar, de probar... vamos, que esta solución es mas sencilla y mas elegante, es mejor.

Sin sabor y sin sustancia

2008-03-10T21:52:00.003+01:00

Hoy he decidido aparcar de momento la aplicación que estaba desarrollando (el "viewer"), ya que me he dado cuenta que no está bien enfocada y su desarrollo no tiene un final feliz. La idea de los módulos no me parece extensible o generalista, por lo que desarrollar esta aplicación con esta filosofía es una pérdida de tiempo.

Para encontrar un nuevo enfoque he vuelto ha jugar con el robot, buscando un nuevo camino para programarlo y encontrar así una fórmula mágica aplicable a cualquier problema. Así que he jugado con hilos, con subprocesos, con señales y temporizadores, lo he sofrito todo a fuego lento en una sartén con dos cucharadas de aceite virgen extra, un poquito de especias y... ha quedado una pasta sin sabor alguno.

Si ya de por sí la biblioteca de python para el NXT está mal documentada, me encuentro con un extraño síntoma que no se como buscar en "san google". El ladrillo, después de dos o tres ejecuciones se queda silbando y con los motores en un estado epiléptico en el que quieren rodar cada uno en un sentido, así que es necesario reiniciarlo para que funcione bien.

Y después de varios días sin recoger frutos ni ver un campo fertil me surge una duda existencial, ¿de verdad se programar?, ¿es python un lenguaje de programación?, ¿será mi robot un cabecilla en la rebelión de las máquinas?

Caminando en silencio

2008-03-04T09:05:00.004+01:00

He estado demasiado callado estos días, y es que lo poco que avanzo no es visible. Sigo desarrollando la aplicación Nxt Viewer y ahora estoy bastante atascado, los problemas vienen a la hora de detener los procesos 'hijo' ejecutados (los módulos) ,no consigo capturar la señal SIGCHLD para que tengan una muerte limpia (y hayá donde vayan tengan una feliz estancia). Así que estoy pensando en dejarlos en estado zombie por el resto de los tiempos... algo que atenta contra todo lo aprendido en sistemas operativos (y la ética)

Por si alguien ve algo que yo no consigo ver, os comento la situación:

La aplicación permite ejecutar otros programas, y cuando estos mueren, las buenas formas dicen que el proceso padre (en este caso mi aplicación) debe recoger los restos de su hijo para que este tenga un funeral digno. Para esto, el sistema operativo me envía la señal SIGCHLD ante el fallecimiento de un proceso hijo. Para capturarla python me proporciona la función signal(signal, manejador). Hasta aquí todo bien, pero... cuando se lanza esta señal por parte del sistema operativo lo que capturo es una SIGINT, y a pesar de ignorarla o asociarla a funciones de tratamiento absurdas, siempre mata a la aplicación (tratamiento por defecto).

¿Alguna sugerencia?

NXT Viewer - Versión de desarrollo

2008-03-02T11:13:00.003+01:00

Sigo con el desarrollo de la aplicación, desde la toma de contacto que representa la versión 0.1 he aprendido unas cuantas cosas. He remodelado el aspecto gráfico de la aplicación, ahora dispone de dos partes diferenciadas

La parte superior está destinada a la conexión con un brick (de momento sólo con uno) y a mostrar información acerca de este ladrillo

La parte inferior permite cargar módulos que ejecutar en el brick conectado, administrándolos de forma simultánea o por separado

Según tenga versiones funcionales intentaré publicarlas por si queréis echarle un vistazo al código

NXT Viewer 0.1

2008-02-29T19:33:00.003+01:00

Bajo este nombre estoy desarrollando una aplicación que espero me ayude en la comunicación con el robot. Esta versión no es mas que una toma de contacto con Glade y su programación con python, su única funcionalidad es conectarse con el 'ladrillo' indicado en la caja de texto (o con el primero que encuentre si está vacía) y mostrar información relativa a él.

En futuras versiones el objetivo es lograr una aplicación que me permita lanzar distintos módulos que interactúan con el robot, es decir, conectar con un robot (o varios, eso ya se verá) y ejecutar distintos programas (o módulos) que interactúen con él.

Buscando aparcamiento...

2008-02-26T13:12:00.004+01:00

Ya tengo algunas pruebas satisfactorias con el prototipo 2 del fisgón. Este modelo busca huecos en las paredes en los que quepa y pasa a través de ellos. Como se puede apreciar, tiene un paragolpes delantero para detener el robot en caso de colisión, pero aún no está implementado, la mayor parte del desarrollo lo ha llevado el control de los motores, cosa que aún no está muy fina.

La misma acción desde otro punto de vista

La partida perfecta

2008-02-26T11:46:00.002+01:00

Buscando un poco de información sobre la integración del mando de la wii con el nxt he encontrado este vídeo, así cualquiera gana a los colegas en los bolos...

Podéis encontrar mas información por aquí

Prototipo A-2

2008-02-21T16:44:00.003+01:00

He realizado algunas modificaciones al primer prototipo. El sensor de ultrasonidos a pasado a un lateral y he incluido el sensor de tacto con un paragolpes.

Me gustó el modelo del coche que aparca sólo, así que para soltarme un poco más con esto estoy haciendo una variante de ese modelo. Mi prototipo sigue una pared hasta encontrar un hueco lo bastante grande como para entrar por él.

Hasta ahora las pruebas funcionan bastante bien, tengo problemas con la inercia adquirida por el vehículo que hace que los giros no sean de 90º (si no un poco mas). Aún no sé como frenar los motores, seguiré investigando un poco.

Y a esto se suma otro problema, y es que la ley de Murphy no falla, cuando estás cerca de terminar las pruebas y llegar a un resultado satisfactorio, te quedas sin pilas... espero poder subir un vídeo esta noche, pero dependerá de si para entonces las pilas se han cargado. Por supuesto si alguien quiere donar una batería recargable para el lego yo lo acectaré gustoso :D

El Fisgón de paseo

2008-02-20T11:32:00.002+01:00

Como prometí ayer he subido el vídeo del primer prototipo dando un paseo. Lo se, lo se, menuda tontería, pero a mi me hace ilusión :D. El robot, como comenté en el post anterior, evita chocar con las paredes, girando 90 grados a la derecha para continuar el camino.

Hoy haré una pausa, ya que tengo otros compromisos, pero espero poder hacer mas cosas con este prototipo y el resto de sensores. Espero que os guste.

De paseo por los pasillos

2008-02-19T22:48:00.003+01:00

"El Fisgón" ya está de paseo por los pasillos de casa, siento no acompañar un vídeo, mañana en un rato lo grabo y lo subo a youtube para que podáis verlo. No es gran cosa, sólo es una prueba de contacto con los sensores y los motores (benditos motores, las vueltas que me han hecho dar...)

El robot ejecuta un algoritmo sencillo, avanza hasta encontrar un obstáculo (en su línea de visión) a menos de 20 cm, retrocede y gira a la derecha, luego vuelve a empezar.

Lo bueno:

No se choca
Ya entiendo bastante mejor a los motores y el tacómetro

Lo malo:

Es mas simple que una ameba
¿Sirve para algo?

Sensores: Luz

2008-02-19T13:50:00.003+01:00

El sensor de luz nos permite identificar varias escalas de grises, existe otro sensor para el color, pero este no está incluido con el paquete mindstorm. A pesar de que para explotar su utilización al máximo sería necesario calibrarlo (por temas de iluminación relativa) no existe aún soporte en NXT-Pyton. Los métodos de uso son similares a los ya vistos

get_sample()

Devuelve en tanto por 100 la cantidad de luz "vista"

set_illuminated(boolean)

Enciende (True) o apaga (False) el haz de luz que varía la cantidad de luz percibida por el sensor. Por defecto este haz de luz es encendido, así que al terminar de utilizar el sensor es aconsejable apagar la luz para no quedarnos son pilas

Sensores: Sonido

2008-02-19T13:27:00.004+01:00

El sensor de sonido permite percibir sonidos audibles para el ser humano (dBA) y sonidos que pueden quedar por encima o por debajo del umbral humano (dB). Por defecto el sensor está configurado con dBA

get_sample()

Devuelve en tanto por 100 el sonido ambiente, según la escala de valores de Lego los márgenes son los siguientes:

4 - 5%: Una habitación en silencio
5 - 10%: Alguien hablando a una distancia lejana
10 - 30%: Una conversación o música a un nivel normal
30 - 100%: Gente gritando o música alta

set_adjusted(boolean)

Establecemos el modo de funcionamiento del sensor, si el parámetro pasado es True, el modo de funcionamiento pasa a ser dBA, en caso contrario (False) será dB

Sensores: "Tacto"

2008-02-19T12:04:00.005+01:00

El sensor de tacto, o "touch sensor" es el mas sencillo de todos. Sirve para detectar una presión, no puede inicializarse ni calibrarse. Es muy útil para detectar el encontronazo con objetos.

get_sample(): boolean

Devuelve un valor true / false que determina si el sensor está presionado (true) o no lo está (false)

is_pressed(): boolean

Ídem al anterior en cuanto a funcionalidad, puede ser mas útil a la hora de leer el código que su predecesor

Sensores: Ultrasonidos

2008-02-19T11:16:00.004+01:00

Este sensor (que parece la cabeza de Jhonny 5) utiliza el mismo mecanismo que los murciélagos para orientarse. Emite un sonido de baja frecuencia y se basa en el tiempo transcurrido desde su emisión par determinar la distancia con los objetos. Su manejo es muy sencillo, dispone de un sólo método para obtener la información y no admite inicializaciones.

get_sample()

Devuelve un valor entre 0-255 representando la distancia en cm con un margen de error de + / - 3 cm.

El robot que aparca solo

2008-02-18T23:15:00.004+01:00

Os dejo otro vídeo, este hace ya mucho tiempo que lo había visto, pero hablando con Bea hace un rato me he acordado de él y he pensado que podía gustaros. Imagino que la longitud del coche la calcula de antemano, es decir, conoce cuantas vueltas han de dar las ruedas sin encontrar la pared para saber si el coche cabe en el hueco

Echando un vistazo al perfil de este usuario, se puede encontrar una evolución del mismo sistema de aparcamiento. ¡Este es una monada!

El nuevo VW Touran incluye un sistema de asistencia de aparcamiento muy similar al de este robot, no he podido probar el sistema de VW (en los concesionarios siguen mirándome mal) pero no creo que sea tan bonito como en el anuncio...

Prototipo A-1 (El fisgón)

2008-02-18T19:59:00.007+01:00

Basándome en el modelo de "The mayan adventure" he creado un prototipo para la toma de contacto con python y el bluetooth. Con este chasis puedo probar sin problemas los distintos sensores y los motores, aunque no creo que me sirva para una implementación seria futura.

De momento las pruebas con los motores no me han dejado muy contento, es necesario sincronizarlos para que el robot no se vaya hacia las cunetas. El sensor de ultrasonidos hasta ahora me ha dado un resultado satisfactorio, ya veremos las pruebas de mañana

Robot para resolver el cubo de Rubik

2008-02-18T19:39:00.004+01:00

Os dejo uno de los muchos vídeos de youtube con robots basados en NXT que resuelven el cubo de Rubik. Y yo que no tengo ni idea de como se resuelven estas cosas...

Os presento a Benito

2008-02-17T23:08:00.006+01:00

Así se llama el robot bípedo que construí con el NXT. No lo bauticé así por la serie de Manolo y Benito, aunque ahora que lo pienso, tampoco habría sido mucho desatino. El caso es que ha sido este el modelo que me permitió hacer mis primeros pinitos con el lego.

Os dejo una foto suya por que en unas horas dejará de tener esta forma y pasará a ser el chasis sobre el cual realizaré las primeras pruebas del protocolo de comunicaciones

¡Qué empiece el espectáculo!

2008-02-17T22:11:00.005+01:00

Como dijo un sabio chino "todo llega para el que sabe esperar", y hoy, 17 de febrero, comienzo el proyecto fin de carrera. Para los que me conocen personalmente saben que ha sido un camino muy largo, con bastantes altibajos, unos años fueron buenos, y otros fueron menos buenos. A todos ellos les dedico estas entradas para así hacerles partícipes de los penúltimos (será mejor que demos nada por sentado) pasos en la universidad.

Mi TFC estará centrado en la robótica, aún no tengo claro que aplicación práctica le encontraremos al aparato, pero mientras tanto hay bastante tarea que hacer. A saber:

Un chasis robusto para soportar todo el robot
Empaparme mucho de la librería NXT_Python con la que desarrollaré la parte software del robot
Investigar mucho sobre el mando de la Wii y sus posibilidades como complemento para mi proyecto

La parte mecánica del robot estará basada en el juguete (si podemos llamarle así) de Lego, NXT Mindstorm. Su plataforma y el ejército de piezas que le acompañan permiten una gran flexibilidad en el apartado físico, ya que no tenemos necesidad de soldar o rebuscar por los cajones en busca de un tornillo que nos sea útil.

Y hasta aquí la primera entrada. Mi idea es acompañarlas con vídeos e imágenes del robot, para que todo este asunto sea un poco mas ilustrativo y menos aburrido.

¡Nos leemos!