A SPLICE oriented Design for theClockwork Orange Robotic Soccer
Integration of a Software Architecture Incorporating an Explicit
Data-oriented Coordination Model into a Distributed Real-time
Intelligent Autonomous System
Masters Thesis Computer Science
University of Amsterdam
10th October 2002
Author : S.C.J Doodeman
Zuidermeerweg 27, 1652 CS Zuidermeer, NL
Supervisor : Prof. drs. M. Boasson
Kruislaan 403, 1098 SJ Amsterdam, NL
Study : Computer Science
Direction : Technological Computer Science
Specialization : Architecture and Intelligent Autonomous Systems
Date : October 2002
Institution : Intelligent Autonomous Systems Group,
Faculty of Science,
University of Amsterdam, NL
Keywords : 1. Software Architecture, 2. Distributed Computing,
3. Intelligent Autonomous System 4. SPLICE, 5. RoboCup
In the second half of the 80s, a number of models and metaphors havearisen that explicitly deal with the concurrency of cooperation in distributedsystems. They had one thing in common, they considered programming adistributed system to consist of two distinct activities: the computing partconsisting of a number of processes involved in manipulating data, anda coordination part responsible for the communication and cooperationbetween these processes. Since that time it has been recognised that ar-chitectures incorporating explicit coordination models enhance modularity,the reuse of existing components, portability and language interoperability.A number of these architectures, focus on distributed reactive systemsand provide additional facilities for distribution of data and processes,fault-tolerant behaviour, graceful degradation, and dynamic reconfiguration.
In 1997 a project started as a cooperation between the University ofAmsterdam, Delft University of Technology and Utrecht University toparticipate in the RoboCup. One of the aims was to develop software fora competitive robot soccer team. Although the merits of separation ofcoordination and computation had been demonstrated by then, the designdecided for relied on message passing for communication, and coordinationas an implicit part of the computation. The problems arising due to a lackof robustness of the system were resolved by practicing ad-hoc solutions,and patchwork programming. The lack of flexibility of the architectureresulted in multiple implementations of code with equal functionality indifferent modules of the system, and large, difficult to comprehend modules.
In the first trimester of 2000, I attended a course which discussed Com-plex Industrial Systems. A system providing support for integration in dis-tributed reactive systems was presented, called SPLICE. I was surprised bythe elegant and simple approach it took to solve problems associated withparallel and distributed systems.
January 2001 I started working on my graduation project. The assignmentconsisted of reorganising the RoboCup software, in such a way that allrobots, as well as their internal components, cooperate by using the facilitiesof SPLICE, and evaluating this solution.
For a number of reasons, this proved to be more difficult than thought.One of the problems was the uncrystallized state of the software existingat the time. Another problem (partially resulting from this) was a lack ofdocumentation for the system modules. In the RoboCup project, graduatestudents usually work on a single module for their project. While theyare working on it they are considered maintainers for the module. When Istarted my project, four modules were being developed in this way. Since itis science we are talking about, my colleague students were experimenting,and experimental code was the order of the day. Sometimes simply to seewhether or not a thought they had would work, or to see how well it wouldperform. Aside from that there was always the call of the tournaments. Toensure a functioning team when a challenge started, some frantic hackingtook place for a short period before (and occasionally during) a tournamentor demonstration would take place.
In order to circumvent the uncrystallized state of the software, I decidedto take a working snapshot of the system, and disregard all modificationsto the software made later. Unfortunately, as mentioned earlier, most ofthe code was undocumented. That is to say: all of it was undocumentedon a functional level, but some of it had documentation on the API levelof the modules. Documentation on a functional level comprises the waythe modules perform their functionality internally, how these functionalcomponents interrelate, and - once implementation would begin - whatparts of the code were associated with this. I needed this information sinceit was no option to maintain the structure of the modules as they were, aswill be explained in chapter 4.
I tried to get this information by talking to the module maintainers, butsome were not able to answer my questions since they were just started withtheir projects themselves, and did not have a clear idea of what functionalcomponents their modules consisted of. Others seemed somewhat preoccu-pied, and had their own worries. Which is understandable when you aretrying to design and code a module at the same time, and fix bugs, andadapt the module you are working on to provide functionality another mod-ule needs in order to make it possible for the robot team to play a decentgame of robot soccer, and write your thesis as well... So I decided to wait forbetter times (I still liked the idea of using SPLICE for the RoboCup projectand was determined to go on with it). Meanwhile I studied some literatureand wrote chapter 3.
May 2002 better times arrived. The documentation I needed becameavailable in the form of graduation theses. Based on this information Iwas able to design the architecture presented in chapter 5. I will probablynot implement it, let alone evaluate the implementation. Nevertheless inthis thesis, I try to show the potential benefits of using a SPLICE basedarchitecture for the RoboCup.
I owe all I learned the past five years to the members of the Faculty ofScience and the University of Amsterdam; five years of education I wontlikely forget. Thanks also to the following people: Wouter Caarls, Bas Ter-wijn, Jeroen Roodhart, Edwin Steffens, Nikos Vlassis, Frans Groen, JurjenCaarls, Werner Altewischer, Robert Bartelds, Pieter Jonker, Tijn van derZant, Marco Wiering, Erik Boasson, Edwin de Jong and to Matthijs Spaanand Raymond Donkervoort for collaboration in writing the introduction ofthe RoboCup software and hardware.And in conclusion, I would like to reserve some special thanks for
Maarten Boasson for supervising my graduation project.
I think thats enough prefacing. Enjoy the text!
Bas DoodemanUniversity of Amsterdam, NL
A consortium of the University of Amsterdam (UvA), the Vrije Universiteit(VU), Delft University of Technology (TUD), and Utrecht University (UU),has developed software for RoboCup. The software is based on a distributedshared world model of the - for the robots relevant - world, i.e. the playing-field, the ball, the positions and behaviour of other robots of both teams.Every robot decides what role it should perform based on this world modeland a number of rules of conduct.The current implementation of this concept uses a communication mech-
anism originally developed at the TUD, which is used by the robots to ex-change local state information to build a shared representation of the world.Unfortunately, because this communication mechanism is based on messagepassing with coordination as implicit part of computation, the resulting ar-chitecture has become rather static.To overcome this, the idea arose to redesign the system based on
SPLICE. SPLICE provides architectural support for real-time distributedsystems. It incorporates an explicit data-oriented coordination model, andutilizes the subscription paradigm. This results in a more flexible architec-ture for which design, implementation, and maintainance is greatly simpli-fied. Due to the increased modularity of the architectural components it iseasier to increase robustness of the system. In addition to this, architecturalcomponents can easily be interchanged by alternatives providing the samefunctionality through another approach. Therefore researching what methodwill perform best for a certain subproblem will require far less effort, andmore time and energy is left for to perform true scientific research.
1 Introduction 11.1 RoboCup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Software Architecture . . . . . . . . . . . . . . . . . . . . . . 51.4 Organization of this Thesis . . . . . . . . . . . . . . . . . . . 7
2 Functionality 92.1 Software Architecture . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Virtual sensors and actuators . . . . . . . . . . . . . . 102.1.2 Tactics and strategy . . . . . . . . . . . . . . . . . . . 12
2.2 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.1 The Message Passing System . . . . . . . . . . . . . . 172.2.2 Deviations from the communication specification . . . 19
3 Coordination 213.1 Coordination Languages and Models . . . . . . . . . . . . . . 21
3.1.1 The Coordination Paradigm . . . . . . . . . . . . . . . 223.1.2 Coordination Models and Languages . . . . . . . . . . 223.1.3 Classification . . . . . . . . . . . . . . . . . . . . . . . 23