Last modified 8 years ago Last modified on 29/05/13 10:10:06

Lab Course Robot Communication and Coordination - Winter term 2012/2013

The goal of this lab course is to design, develop and test methods to implement communication facilities for intelligent robot agents. The scenario is the RoboCup Logistics League Sponsored by Festo for a group of up to three cooperating robots. By the end of the semester a demonstration should show how the communication facilities can be used to coordinate the robots to cooperatively solve a specific task.


  • Anne Kathrein
  • Leonardo Antunes
  • Hendrik Pesch


  • Tim Niemueller
  • Stefan Schiffer


Recently the Knowledge Based Systems Group have implemented an autonomous agent competing in the RoboCup Logistics League. In our specific case the ruleset describes a "production game" where robots must operate a production line. This paper describes an approach for the single-agent case of this production game, where a single robot is responsible for the whole production chain.

In order to accelerate the production chain our responsibility was to develop a multi-agent solution where individual agents cooperate and communicate. Our focus was developing the infrastructure needed for such communication between the agents. For testing purposes we designed a communication protocol for a specific scenario.

Particular Scenario

Information on the on the task can be found here

Our solution

We give some implementation details on the scenario for 2 Robotinos, Master and Slave, which produce an S2 at a T2 machine.


For the provided simple scenario, we extend the robotino-clips-agent plugin and introduce the coopcoom plugin. In order to accomodate the different roles in the proposed scenario (master and slave), the clips-agent plugin had its clips rules split in two, each loaded according to its respective role. Communication between both roles is then performed in two levels:

  • Agent information is exchanged making use of broadcast assertions that are sent to all clips-agents instances (optionally being locally asserted as well). More details are given below.
  • World state information (see section below) is synchronized via the coopcomm plugin, which observes world information via blackboard and broadcasts changes only to other coopcomm instances. The robotino-worldmodel plugin was also extended to integrate information received by coopcomm back into the local worldmodel.

Both systems utilize the underlying messenger library, which is an abstraction on the more low level network communication routines for resilient broadcast communication across multiple threads.

The previous ruleset for single-agent production was adapted for use by the master, keeping the slave's rules simple: executing whatever instruction is provided by the master. For the provided scenario, only rules dealing with the fetching of S0 pucks and delivery to T2 machines are handled. The master's instructions themselves are coded as an assertion of the form "take puck X to machine Y". The general execution of the scenario is as follows:

  • The master identifies a T2 machine and broadcasts a task for the slave to bring an S0 to it.
  • The master then fetches an S0 puck before the slave (guaranteed through locking) and produces an S1 utilizing the previously available single-agent rules.
  • After producing an S1, the master waits for the slave to accomplish its task of loading a given T2 with an S0.
  • Finally the master delivers its S1 to the T2 concluding the production cycle of a S2.

To avoid deadlocks and collisions, locking is utilized for all machines (including the S0 input area) and after completing a certain task (fetching S0; delivery at machine; etc) a sidestep is performed, to give the other robotino a chance of also reaching the same position in case no further actions are available (for instance after the slave delivers its S0 to the target machine).

World State Information

World state information is defined by the robotino-worldmodel-plugin. It is comprised of a description of all machine types and machine states in the LLSF game.

Broadcasting Messages

The underlying system for transmission of messages is the messenger library. It utilizes protobuf as a wire-level format (available in the src/libs/protobuf directory, for concurrent access by plugins and utilities - like msgsend for debugging) and DatagramBroadcastSocket as the fawkes-specific network abstraction layer. Each protobuf protocol (each plugin has its own) utilizes a different port, to make sure plugins only receive messages they are actually interested in and to obviate the need for more complex buffering for each user of the library. Furthermore, the messages themselves are sent a configurable amount of times, so that they are received with high probability.

As mentioned above, the messaging can be broken down in two main groups. For rapid prototyping, the agent code only employs three types of messages:

  • A task message type, explicitly used for task-assignment.
  • An assertion message type, the generalization of the above, used for arbitrary cross-agent assertion. Further work: this can either supplant the task message type, or be supplanted by more specific message types for the other functionalities that make use of it (locking and simulation synchronization).
  • An eval message type for debugging purposes.

The coopcomm plugin has only two types of messages:

  • TypeChange: to be used in the future as robotinos discover machine-types during a game.
  • StateChange: used to inform other agents about pucks being added/removed from machines.

Both message types reflect the information currently being stored by the robotino-worldmodel plugin in its blackboard interface.

Additionally, the simulation code (used when use-sim:true by clips-agent) has been extended to make use of this infrastructure to propagate changes in the simulation-state. This is especially advantageous since the simulation code already runs on CLIPS and this way all simulation-related code remains in a single place.

Implementation of the Scenario in CLIPS

The CLIPS files were extended by dividing them into rules_master, rules_slave, and rules_single, where the last file contains the clips functions which were implemented for single-agent production.

For our concept of "task", the master sends out the above mentioned task message type, which includes a puck type and a machine name to which the puck should be taken. Upon receipt of this message, the slave asserts a target-machine fact and - since the S0→T2 case is the only one currently handled - asserts a get_s0 fact, which triggers the fetching of an S0 puck. The target-machine fact is necessary for this "multi-level" planning of fetching an S0 while not forgetting its intended future destination.

The master rules, on the other hand, besides chosing a T2 and assigning the slave's task, are only changed in order to avoid the single-agent case where the master itself would bring an S1 to the T2, and to simply wait for the task's completion by the slave.

This short code example shows how the task is assigned to the slave by the master:

(defrule get-s0
  (state IDLE)
  (holding NONE)
  (machine (mtype ?mt&T2) (name ?name))
  (not (target-machine (name ?)))
  (if (debug 1) then (printout t "Need to get S0" crlf))
  (assert (target-machine (name ?name)))
  (assert (get-s0))
  (assign-task "S0" ?name)

It is defined in the rules which only the master holds. After the master robotino is started he selects a machine of type T2 and assigns the task. The relevant part of this rule, regarding the communication, is the last line which calls the function assign-task, which in turn calls broadcast-assert.


The robotinos should not attempt to move to the same location at the same time, to avoid overtaxing the colision-avoidance. Therefore the Master robotino holds locks on the different locations via a fact

(has-lock (agentID ?a2) (position ?p))

The master is responsible for managing locks, but even its own locks are managed in the same fashion as those for the slave, i.e.: among the skill-related rules, a request for a lock is performed and an independent ruleset either provides the lock or denies the request.

This is implemented in the following structure:

  • lock.clp holds general locking rules:
    1. If a robotino wants a lock it broadcasts a fact (get-lock (agentID ?a2) (position ?p)). This is either excepted by the master, in which case the master broadcasts the fact (lock (agentID ?a2) (position ?p)), or refused, in which case the assertion sent is (refuse-lock (agentID ?a2) (position ?p)). The latter case occurs if the position is already locked by an other robotino.
    2. For locking phase additional states LOCKING and WAIT_LOCKING were added so that no other rules are executed during locking.
  • lock_master.clp:
    1. Manages the lock requests themselves.
  • lock_slave.clp:
    1. Unlocks resources that have been locked after completion of the involved action.


Further instructions on utilizing the new proposed librariy and plugins can be found here

Robotino-Agent Plugin

Information on the robotino-agent-plugin can be found here

Coopcomm Plugin

Information on the coopcomm-plugin can be found here