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.

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

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.

Algunos avances

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

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.