Middleware and Functional Architecture

Plan representation has been based so far on state machines or Petri nets, where states (or places, in the case of Petri nets) represent a primitive action (e.g., APPROACH_BALL, RUNANDKICK). Note that, in Petri nets, the state is distributed through several places. In this context, a state always includes one or more primitive actions currently running plus possibly other places associated to relevant information, including communictions from teammates. Behaviors (e.g., GetClose2Ball, TakeBoal2Goal) group primitive actions as a "macro-action". When a (logical condition on) a predicate (e.g., SEE(OWN_GOAL), NEAR(BALL) AND SEE(OWN_GOAL)) changes truth value, an event occurs (e.g., LOST_BALL when SEE(BALL) changes from TRUE to FALSE). Events are associated to the transitions among states and cause jumps between them.

The middleware and architecture are preliminarily described in this paper: Marco Barbosa, Nelson Ramos, Pedro Lima, "Mermaid - Multiple-Robot Middleware for Intelligent Decision-Making", Proc, of IAV2007 - 6th IFAC Symposium on Intelligent Autonomous Vehicles, Toulouse, France, 2007 Recently, we released the latest version of MeRMaID:

• svn repository at svn://svn.isr.ist.utl.pt/mermaid/trunk/mermaid-support/
• documentation here

SocRob's original software architecture (1998-2005) was based on a set of threads (here called micro-agents, for completion) which exchanged data among them and with the hardware (sensors, actuators) through a distributed blackboard (BB). Data in the blackboard included raw and processed data local to one robot, as well as processed data originated in its teammates. Some BB variables were updated only locally (e.g., most recent sonar data), but others were broadcasted every time they were updated (e.g., robot1_posture, ball_location).

A diagram of the original software architecture follows.