Software básico del robot (Parte II)

En esta entrada seguiremos hablando sobre el software del robot. Antes de describir con detalle las partes del código que todavía no hemos explicado, lo cual haremos en la siguiente entrada, es necesario entender cómo es una arquitectura subsumption para la programación de robots.

¿QUÉ ES LA ARQUITECTURA SUBSUMPTION?

La parte de la lógica del robot que establece las diferentes acciones que puede ejecutar está implementada mediante una arquitectura subsumption. Esto quiere decir que, para reducir la complejidad de su inteligencia hemos creado pequeños módulos de comportamiento (que llamaremos “behaviours”) muy simples.

Toda arquitectura subsumption tiene dos componentes fundamentales:

• Comportamientos (behaviours): Cada una de las tareas u objetivos que forman el algoritmo de control del robot debe ser separado en un módulo distinto. Todos estos módulos deben tener una condición de inicio (algo que se debe satisfacer para que el comportamiento tome el control del robot), una acción a ejecutar en el momento de tomar el control y otra acción a ejecutar cuando se termina de ejecutar el comportamiento del robot (por ejemplo, cambiar el estado de algún indicador). Además, es necesario que estos comportamientos tengan una escala de prioridad para saber cuáles son más relevantes que otros.
  
  
• Árbitro: Es el encargado de iniciar la ejecución de los comportamientos y dar el control al comportamiento correspondiente si se cumple su condición de inicio. Si en el mismo instante se cumplen las condiciones de inicio de varios módulos, él sólo permitirá que el de mayor prioridad tenga el control.

Esta arquitectura ofrece grandes ventajas a la hora de programar un robot: se pueden añadir nuevos comportamientos o eliminar alguno de los existentes sin afectar al resto del código y es muy fácil de entender, por el hecho de haber dividido el algoritmo en bloques sencillos.

¿CÓMO PODEMOS IMPLEMENTAR ESTA ARQUITECTURA?

El entorno de desarrollo LeJOS nos ofrece la librería Subsumption, con todas las herramientas necesarias para crear y gestionar comportamientos:

• Interfaz Behavior. Nos permite crear cada módulo de comportamiento y definir todas sus características a través de tres métodos abstractos:
  -boolean takeControl(): En el momento en el que devuelve un valor verdadero, el árbitro le cede el control del robot a este comportamiento (siempre y cuando no se cumpla la condición de inicio de otro comportamiento de mayor prioridad).
  -void action(): Contiene la tarea a ejecutar por el robot cuando este comportamiento se vuelve activo.
  -void suppress(): Es el método que se ejecuta en cuanto se termina la ejecución del action(). Debe ser un método corto; generalmente se usa para cambiar el valor de algún flag.
  
• Clase Arbitrator. Es la clase encargada de gestionar los comportamientos según su importancia y dar el control a cada uno cuando se cumplen las condiciones de inicio. Para construir un objeto de esta clase, es necesario pasarle como argumento un array de Behaviors ordenados de menor a mayor prioridad. Una vez que se lanza el árbitro con su método Public void start(), éste llama al método takeControl() de cada Behavior, empezando por el de mayor prioridad, hasta que encuentra alguno que cumple la condición de inicio. En ese momento, le cede el control al comportamiento correspondiente para que ejecute su método action() una única vez.
  
  

Con todos estos conceptos teóricos y la librería Subsumption, ya tenemos los elementos necesarios para diseñar e implementar los comportamientos de nuestro robot. Al igual que nos ocurre a los seres humanos, ciertas acciones tendrán más prioridad que otras. Por ejemplo, si una persona o un robot decide andar y en su camino encuentra un obstáculo, deberá tener más prioridad el comportamiento de “evitar obstáculos” que el de “andar”. Esta filosofía será la que aplicaremos a la hora de crear el array de comportamientos de Kigo.