Brainsormers Tribots cognitive architecture

To be successful in making a robot play soccer, the control software must be able to generate a senseful behavior of the robot in all situations that might occur during a soccer match. This is typically done in a certain part of the control software that implements the strategy of the soccer player. Simple strategies like “Always go to the ball and kick” which can be implemented in a few hundred lines of code are not competitive any more in the MiddleSizeLeague. Instead, the strategy must distinguish many different situations and provide specialized movements for any of them. The strategy must take into account the position and movement of the ball, the own position, the teammates' and opponents' positions, other obstacles that might be on the soccer field, the soccer rules, the presumptive behavior of the teammates, etc.

In order to be able to create such a complex strategy, to easily maintain and refine it, and to be able to understand what is happening during a soccer match, the software must be well structured and the idea of individual movements for special situations must be integrated in the underlying software design. Due to the similarity to human decision making these kind of software architectures are also named cognitive architectures.

The software architecture developped by the Brainstormers Tribots combines ideas from Brooks' subsumption architecture and Rao&Georgeff's BDI (belief, desire, intention) architecture (originally proposed by Bratman, Israel&Pollack). The basic principles are:

• The strategy is subdevided into several small units, called behaviors. Every behavior can serve as a strategy itself in some situations. Examples are “go to the ball”, “dribble the ball along the sideline into the opponent half”, “perform a kick into the opponent goal”, “go to a position to execute a free kick”, etc.
• Each behavior is equipped with three main functions:
  • generate a driving command: this function generates a driving command that is appropriate to achive the goal of the behavior, e.g. arriving at a certain position, executing a kick, etc. The behavior can ask other parts of the software (e.g. the world model) to get the relevant information about the robot position, ball position, obstacles, etc.
  • invocation check: this boolean function checks whether the pre conditions to execute this behavior are met. E.g. a dribbling behavior must be sure that the robot is already in ball posession when it is executed. Otherwise, the behavior cannot generate a senseful driving command.
  • commitment check: this boolean function checks whether the behavior can continue. E.g. in the case of a dribble behavior the behavior can only generate further senseful commands if the robot does not loose contact of the ball.
• Behaviors can be combined to form more complex behaviors using generic arbitrators (BDI-behaviors). Behavior hierarchies can be built. The whole strategy itself is a BDI behavior.

Each behavior can be seen as an autonomous piece of strategy. The invocation and commitment conditions specify in which situations this behavior generates senseful driving commands. Hence, an external scheduler can check which behavior among a set of behaviors is prepared to generate a senseful driving command even without knowing which movements are implemented in the behaviors.

The idea of an automatic scheduler is implemented in the BDI-behaviors. They are build out of a set of candidate behaviors (called options) which are arranged in a priority queue. One of the options that has been asked before to generate a driving command is called the intention. In each step, the BDI behavior checks the commitment condition of the intention and the invocation conditions of the other options to check which of them are prepared to generate a driving command. Among those, the one with the highest priority becomes the new intention and is asked to generate a new driving command.

The concept of individual behaviors and generic BDI-behaviors allows to refine the strategy easily without getting non-maintainable code. New, very specialized behaviors can be added and do not interfer with the existing software. Moreover, using a behavior-logging system we are able to track which behaviors were active (i.e. which option became intention) during a soccer match.

The following illustration shows the transition graph of a defender during the final of robocup 2006: