domingo, 21 de septiembre de 2008

Nuevo sensor EOPD

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.

viernes, 19 de septiembre de 2008

Comportamiento (III): Barras Verticales

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)


martes, 16 de septiembre de 2008

Nuevos Prototipos


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

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.


jueves, 11 de septiembre de 2008

Comportamiento (I) : La lógica

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

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

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



lunes, 8 de septiembre de 2008

En breves momentos...

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.