A SPLICE oriented Design for theClockwork Orange Robotic Soccer
Team Software
or
Integration of a Software Architecture Incorporating an Explicit
Data-oriented Coordination Model into a Distributed Real-time
Intelligent Autonomous System
Master’s Thesis Computer Science
S.C.J. Doodeman
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
Preface
In the second half of the 80’s, 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.
ii Preface
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.
iii
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 won’tlikely 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 that’s enough prefacing. Enjoy the text!
Bas DoodemanUniversity of Amsterdam, NL
Summer 2002
Summary
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.
Contents
Preface i
Summary v
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
3.2 Software Architectures Incorporating Coordination Models . . 233.2.1 Linda . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 GAMMA . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Distributed Reactive Systems . . . . . . . . . . . . . . . . . . 263.3.1 Data Flow Types . . . . . . . . . . . . . . . . . . . . . 263.3.2 Non-functional Requirements . . . . . . . . . . . . . . 273.3.3 Coordination in Distributed Reactive Systems . . . . . 28
3.4 Software Architectures in Distributed Reactive Systems . . . 293.4.1 ETHNOS . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.2 NDDS . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.3 SPLICE . . . . . . . . . . . . . . . . . . . . . . . . . . 32
viii CONTENTS
3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4 Transition 374.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.2 Autonomy . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.3 Communication . . . . . . . . . . . . . . . . . . . . . . 394.1.4 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3 Information flows . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Redesign 435.1 Hardware Abstraction . . . . . . . . . . . . . . . . . . . . . . 43
5.1.1 Self Position Estimation . . . . . . . . . . . . . . . . . 445.2 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2.1 Trajectories . . . . . . . . . . . . . . . . . . . . . . . . 465.2.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 475.2.3 Identification . . . . . . . . . . . . . . . . . . . . . . . 475.2.4 Properties . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3 Team Coordination . . . . . . . . . . . . . . . . . . . . . . . . 485.3.1 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.3.2 Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 Action Selection and Reactive Behaviour . . . . . . . . . . . . 525.5 SPLICE mapping . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.5.1 Data categories . . . . . . . . . . . . . . . . . . . . . . 545.5.2 Worlds . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.5.3 Processes . . . . . . . . . . . . . . . . . . . . . . . . . 55
6 Conclusion 576.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Appendix A: Middle-Size League Rules of Conduct 59
Appendix B: Figures 63
List of Figures
1.1 A Pioneer 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Three Nomad Scouts. . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Hardware setup of the Nomad Scout. . . . . . . . . . . . . . . 3
1.4 The kicker, ball handlers and the ball handling mechanism. . 4
1.5 An agent interacting with its environment [29]. . . . . . . . . 6
2.1 Functional architecture decomposition for one robot. . . . . . 10
2.2 Communication details. The arrows represent the informationflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1 The Odometer process, Vision self localizer process, and theVision shape detector process, representing the sensor side ofthe hardware abstraction layer. Based on the sensor informa-tion, the Self position estimator process and Shape positionestimator process respectively estimate the position of therobot, and the position of shapes perceived by the robot. (Anenlargement of this figure can be found in Appendix B onpage 64). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 The Object tracker process, Trajectory migrator process, Ob-ject identifier process, Object parameter estimator process,Player property determinator process, Ball property determi-nator process, and Goal property determinator process. Ob-jects are tracked, identified, and parameters and object spe-cific properties are determined. (An enlargement of this figurecan be found in Appendix B on page 65). . . . . . . . . . . . 46
5.3 The Strategist process, the Possible role determinator pro-cess, the Attractor, repeller and slope calculator process, thePosition based role evaluator process, the Role utility cal-culator process, and the Role selector process. A strategy isdecided on, for which the possible roles are determined. Forthese roles a utility is calculated. Role utilities of differentrobots are compared, and a role is selected based on the pri-ority of the role and its utility. (An enlargement of this figurecan be found in Appendix B on page 66). . . . . . . . . . . . 49
x LIST OF FIGURES
5.4 Finite state machine to determine the next team behavior. [29] 505.5 The Strategic self positioning evaluator process, the Action
simulator world state composer process, the Action simula-tor process, the Action evaluator process, the Action util-ity calculator process, the Action selector process, the Reac-tive behaviour process, the Action executor process; and theactuator side of the hardware abstraction layer: the Motioncontroller process, the Kicker process, and the Sound playerprocess. Based on the selected role, all actions available tothe role are simulated and evaluated. Based on utilities ofthe actions and the probable actions other players will take,an action is selected and executed. The Reactive behaviourprocess monitors the current world state, and publishes re-flex actions accordingly. (An enlargement of this figure canbe found in Appendix B on page 67). . . . . . . . . . . . . . . 52
6.1 The ball handler rule . . . . . . . . . . . . . . . . . . . . . . . 606.2 The sizes and lines of a robot soccer field . . . . . . . . . . . 60
6.3 This figure is an enlargement of figure 5.1 on page 44. . . . . 646.4 This figure is an enlargement of figure 5.2 on page 46. . . . . 656.5 This figure is an enlargement of figure 5.3 on page 49. . . . . 666.6 This figure is an enlargement of figure 5.5 on page 52. . . . . 67
List of Tables
1.1 The specifications of the robots. . . . . . . . . . . . . . . . . . 5
5.1 Distribution of roles associated with each team strategy. [29] 50
Acronyms
A number of acronyms that are found in the main text are debreviatedbelow.
AI Artificial Intelligence
API Application Programmers Interface
ETHNOS Expert Tribe in a Hybrid Network Operating System
GAMMA General Abstract Model for Multiset mAnipulation
HSI Hue Saturation Intensity
IEEE Institute of Electrical and Electronics Engineers
IP Internet Protocol
NDDS Network Data Delivery Service
PAL Informal: a close friend; comrade; chum
PCL Proteus Configuration Language
RTPS Real-Time Publish-Subscribe model
SPLICE Subscription Paradigm for the Logical Interconnection
of Concurrent Engines
SQL (originally) Structured Query Language
UDP User Datagram Protocol
Chapter 1
Introduction
This chapter introduces the basic notions used throughout the thesis. First Iwill introduce the RoboCup, next I will discuss some design issues regardinga software architecture for distributed systems. After this I will introduceSPLICE, which provides architectural support for distributed reactive sys-tems. Finally I will give a short overview of the organization of this thesis.
1.1 RoboCup
The RoboCup has been introduced by Kitano et. al. [20] in AI Maga-zine as “an attempt to promote AI and robotics research by providing acommon task for evaluation of various theories, algorithms and agent ar-chitectures.” At that time Chess - the common task previously associatedwith AI - was no longer a challenge to the AI research field. Kitano tried toprovide a new challenging task to AI and other research areas by providinga common task to evaluate and integrate a wide range of possibly interdis-ciplinary technologies. The research areas involved with the RoboCup are:agent architecture, combined reactive and modelling-planning approaches,real-time recognition, planning and reasoning, reasoning and action in a dy-namic environment, sensor fusion, multi-agent systems, behaviour learningfor complex tasks, strategy acquisition, and cognitive modelling.
The RoboCup is subdivided into a number of leagues. It consists of asoftware robot league, commonly referred to as the “simulation league”; areal robot league, and the expert robot competition. In the simulationleague, software agents play soccer on a network of computers connectedto a soccer server, which provides the playground, simulation of physics,and enforces the game-playing rules by means of a software referee. In theexpert robot competition, robots compete which have special abilities, butare unable to participate in the soccer game; instead they are challenged todisplay special skills, like shooting penalties and goal keeping. The real robotleague is subdivided into three categories, one for small-, one for middle-size-,
2 Introduction
Figure 1.1: A Pioneer 2.
Figure 1.2: Three Nomad Scouts.
and one for large robots.
A consortium of the University of Amsterdam (UvA), the Vrije Uni-versiteit (VU), Delft University of Technology (TUD), and Utrecht Univer-sity (UU), participate in the RoboCup middle-size real robot league asClockwork Orange (from now on referred to as the RoboCup). This leagueis for robots at least 30cm and at most 80cm in height, with a diameter ofapproximately 50 centimeters. The playing field is a coloured green rectan-gle, which may vary in size between 8 and 10 meters in length, and between4 and 7 meters in width. The rules of the game are comparable to but notcompletely the same as those of human soccer. For instance, the maximumnumber of players simultaneously in the game (including the goal keepers)is eight; each team has four players. Other differences and additions aremade to the rules, mostly regarding limitations of the robots as comparedto human players. For a more detailed discussion of the middle-size rules ofconduct, see appendix A (page 59). The next section describes the hardwareof the robots in some detail.
1.2 Hardware
First of all the robots have to be introduced. The lineup consists of sixNomad Scouts and one Pioneer 2. Delft University of Technology andthe University of Amsterdam own three Nomad Scouts each adapted for the
1.2 Hardware 3
Bumper ring
High levelcomputer
Kick device
Wirelesscommunication
Ball holder
Frame grabber
Low level motor board
Sound system
Camera
Sonars
Motors
Odometer
Figure 1.3: Hardware setup of the Nomad Scout.
soccer game, while the Pioneer 2 belongs to Utrecht University.
The Pioneer 2 (figure 1.1) from ActivMedia Robotics uses a laser rangefinder, 16 ultrasonic sonar sensors, odometry sensors, and a camera for sens-ing. It uses a pneumatic kick device as actuator.
The Nomad Super Scout II (figure 1.2) from Nomadic Technologies hasodometry sensors and one camera for sensing and a pneumatic driven kickdevice as effector. Its 16 ultrasonic sensors and its tactile bumper ring arenot used for RoboCup. The specifications of both types of robots can befound in table 1.1.
A functional overview of the hardware setup of the Nomad Scouts isshown in figure 1.3. The low level motor board controls the original hardwarefrom Nomadic Technologies while the high level computer is connected tocustom hardware like the camera, the kick device and the wireless Ethernet.
The only hardware sensors used are the camera and the wheel encoders.The encoders should be able to tell the rotation of each wheel, from which therobot’s path can be calculated. However, Nomadic Technologies decided notto use the value of the feedback signal coming from the wheel encoders as onewould expect but instead the value of the control signal as computed by thecontroller from the feedback signal and desired speed. The low-level motorboard converts this signal to the expected speed resulting from it, assumingthe robot is free to move. In practice this means you cannot discriminatebetween normal driving or pushing against a static object with slippingwheels.
The camera is a wide angle color PAL-camera from JAI Camera So-lutions. Several features are configurable on this camera, such as the auto
4 Introduction
Figure 1.4: The kicker, ball handlers and the ball handling mechanism.
white balance feature. Configuration can be done manually or by softwarethrough a serial port. For reliable color detection is it necessary that theauto-white balance can be disabled. A standard WinTV frame grabber isused; it has been set to grab 12 frames per second in 640 × 240 pixels YUVformat at 3 × 8 bits color depth.
The Nomads have been heavily customized and currently have four ac-tuators: the wheels, the kick mechanism, the ball holder mechanism andthe sound system. The kick device (figure 1.4) uses compressed air froma 16 bar air container on top of the robot. It is located between the twoball handlers and the distance between it and the convex hull is 7 cm (onethird of the ball diameter, as specified by the rules). The kicking device ofthe goal-keeper is half a meter wide (the maximum allowed width), sinceits objective is not to handle the ball carefully but to just kick it across thefield. On top of the kicker mechanism resides the ball holder mechanism: asmall pneumatic device used to trap the ball for holding. Current RoboCupregulations have deemed this device illegal, therefore it is no longer used.
The motors, sonars, and bumper ring are being controlled by a Mo-torola MC68332 processor on a low level motor board. New motor com-mands are only accepted five times a second which severely limits the amountof control one has over the robot. The Nomad can for instance not be al-lowed to drive at maximum speed because when obstacles are suddenly beingdetected the robot might not be able to stop in time.
The software runs on the high level computer, an Intel Pentium 233MHz based computer on an industrial board, of the so-called biscuit size(5.75” by 8”). Communication with the low level board is accomplished usinga serial port, and a PC 104 card is used to control the kicking mechanism.PCI slots contain the frame grabber and a standard sound card that togetherwith two small speakers form the sound system.
For wireless communication between robots a BreezeCOM IEEE802.11 wireless Ethernet system with a maximum data rate of 3 Mbps is
1.3 Software Architecture 5
Specification Nomad Scout Pioneer 2
Diameter 41 cm 44 cm
Height 60 cm 22 cm
Payload 5 kg 20 kg
Weight 25 kg 9 kg
Battery power 300 watt hour 252 watt hour
Battery duration in game 1 hour 30 min
Max. Speed 1 m/s 2 m/s
Max. Acceleration 2 m/s2 2 m/s2
Special sensors Camera Laser + camera
Table 1.1: The specifications of the robots.
used, allowing the robot to communicate with other robots up to a dis-tance of 1 km. It uses the 2.4 GHz band and finds a frequency which isnot yet fully utilized by means of frequency hopping. During tournamentsthe BreezeCOM system proved very reliable in contrast with the WaveLansystem used by other teams which suffers heavily from interference of otherwireless networking devices in the 2.4 GHz band.
1.3 Software Architecture
The robots in the RoboCup are envisaged as autonomous agents. Figure 1.5depicts an autonomous agent interacting with its environment. An au-tonomous agent is a system that can reach a goal or perform a task that isgiven in terms of parameters or properties of the world around it [32]. Since,in the RoboCup each autonomous agent corresponds with a mobile robot,and more than one mobile robot are involved in the game-play as a team,one team can be seen as a distributed system. A distributed system is aninterconnected collection of autonomous computers, for which the existenceof multiple autonomous computers is transparent [31].
Since a team in the RoboCup is a distributed system, the software ar-chitecture designed for it should match the criteria typically associated withsuch a system. The definition of software architecture I will use through-out this thesis is: A system structure that consists of active modules, amechanism to allow interaction among these modules, and a set of rules thatgovern the interaction. The software architecture of Clockwork Orange, isbased upon a world model shared over all agents. Each agent maintains its
6 Introduction
Agent Environment
Sensor
Actuator
Figure 1.5: An agent interacting with its environment [29].
own idea of the world in a local version of the world model. Informationfrom the local model is combined with the local world models from otheragents, resulting in a shared world model. The shared world model containsrelevant game information like the soccer-ground, the ball, the positions andbehaviour of other robots for teammates as well as for opponents.
Communication
In the current architecture, an agent consists of a number of autonomoussoftware modules. These modules use interface functions on top of a mes-sage passing mechanism to communicate information. This message passingsystem is used for intra- as well as for inter agent communication. For interagent communication this is efficient enough, however information exchangewithin one agent can be achieved much more cost effective by implementinga shared memory scheme. Another aspect of the explicit message passingsystem currently in use in the RoboCup software which is not entirely sat-isfactory, is that it makes the architecture rather static. When sending amessage in this message passing system, a destination alias - consisting ofan IP-address in combination with a module-id - has to be given explicitly.This has the disadvantage that reconfiguring the architecture has to be doneby hand by adapting configuration files, before compiling the system. There-fore runtime (dynamic) reconfiguration is out of the question. If an agent ora module stops functioning, it is impossible to let another agent respectivelymodule take over its task, because the messages intended for it are still sentto the non-functioning unit.
A way to circumvent this, is to introduce an intermediate medium whichon one hand stores the information relevant for more than one module, andon the other hand can be requested by a module on a subscription basisto deliver a particular sort of such information to it. In this system, if it isdetermined that a module or agent has died, it is possible to start anotherinstance of it which takes over. The intermediate medium will be requestedby the new instance to deliver information of the sorts it is interested in,
1.4 Organization of this Thesis 7
and the game can go on.The medium - a shared data space in combination with the subscription
paradigm - in this form just presented has a disadvantage: if the agent whichmaintains the shared data space fails, the entire system will fail. To rid our-selves of this single-point-of-failure the shared data space can be distributedover all agents. By selectively copying the information redundancy is intro-duced, which should be of such an extent, that when m of the n agentsfail n−m agents can continue operation without (catastrophic) informationloss.The distributed shared data space can be implemented in such a way that
each agent has a local cache, all modules of an agent communicate with oneanother through the local cache. All communication with modules of someother agent will go through the local cache, which in turn communicates withthe cache of the other agent. From this cache, the information will be sentto the modules interested in it. The communication with the local cache canbe implemented in shared memory, which is more efficient for intra-agentcommunication than message passing.An architecture based upon a shared data space in combination with the
subscription paradigm, with the refinement mentioned above (distribution)and many other refinements to make the architecture suitable for reactivedistributed systems, is SPLICE. SPLICE is discussed in subsection 3.4.3(page 32).
1.4 Organization of this Thesis
This chapter introduced some basic notions used throughout the thesis.Chapter 2 discusses coordination models and their uses, with some emphasison the data-oriented class of coordination models and SPLICE. Chapter 3describes the functionality of the robot soccer software architecture as it isimplemented at this time.Based on what is discussed in chapter 2 and 3; chapter 4 discusses how
to approach a SPLICE-based redesign based on the current implementationof the software. Chapter 5 presents this redesign and in chapter 6 this thesisis concluded.The appendices contain additional information related to - but not part
of - the main story. Appendix A consist of a discussion of the rules of con-duct of the RoboCup middle-size league. Appendix B contains a number ofenlargements of figures found in the main text.
Chapter 2
Functionality
This chapter discusses the current state of the software architecture of therobots, it describes the functionality of its component modules, and themeans of interaction of these components embodied by the communicationsystem.
2.1 Software Architecture
Delft / Amsterdam and Utrecht have chosen different approaches in intelli-gent agent design. This results in a greater challenge in modelling the teambehaviour: the heterogeneous robots should integrate seamlessly into a team,it is not desirable to have the robots divided into homogeneous sub teams.
Utrecht University’s Pioneer 2 uses an extended version of the subsump-tion architecture [10] in which particular behaviours such as Get Ball, Drib-ble, and Score compete for controlling the robot. All behaviours can reactin correspondence to the world model or to direct sensor data provided bythe local camera and laser range finder.
The Nomad Scouts operate on a hybrid architecture which looks likea classical, hierarchical approach but whose units have a high degree ofautonomy. Figure 2.1 depicts a functional composition of this architecture.On the lowest level reside the virtual sensors and virtual actuators,the higher levels implement the tactics of the robot and the strategy of theteam. A good example of an autonomous unit is the Player skills module.It is a reactive unit as the arrow toward it from Vision object recognitionindicates, which allows it to adjust a direct move command from the Teamskills module when an obstacle appears.
One should keep in mind that the architecture has been designed a fewyears ago ([17], short version appeared in [19]) and evolved over time. Mas-ter’s students from two geographically separated universities each workedon their small part of the project. A lot of effort was spent coordinating thedifferent modules. The functional decomposition in figure 2.1 describes the
10 Functionality
Odometry Motion Kicker Sound
Player skills
Vision objectrecognition
Vision selflocalization
World model
Inte
r ro
bot c
omm
unic
atio
n
Action selectionTeam strategy
Virtualsensor/actuator
Team skills
Strategy
Tactics
Sensors Actuators
Operating system
Reasoning
Figure 2.1: Functional architecture decomposition for one robot.
architecture used for RoboCup 2001.
2.1.1 Virtual sensors and actuators
The lowest level in the software architecture implements the link betweensoftware and hardware. It consists of virtual sensors and virtual actua-tors, which provide an abstraction to the hardware. They don’t communi-cate directly with the hardware but use device drivers from the operatingsystem as intermediates instead.
Odometry
The Odometry module is a virtual sensor which keeps track of the motionof the robot. It gets it data from the motor board1, it provides an estimateof the current position of the robot as well as an estimation of the systematicerror inherent to odometry. To estimate this error, a University of MichiganBenchmark test as described in [9] has been run. For a typical Nomad thiserror turned out to be 20cm after driving a 3m square (1.7%).
1The Motion module passes this data to the Odometry module, since only the Motionmodule can communicate directly with the low level motor board.
2.1 Software Architecture 11
Vision object recognition
The camera supplies the data for our two other virtual sensors. All visionprocessing uses 24 bit colour images of a 320 × 240 resolution, half of theoriginal height. This reduction is necessary because the frames the cameraproduces are interlaced. The camera and vision system on each robot haveto undergo a lengthy calibration procedure every time lighting conditionschange.
Vision object recognition[18] extracts objects like the ball, the goalsand robots from these camera images. This is done by means of image seg-mentation based on colour detection. For this purpose the HSI colour sys-tem is very suitable. The HSI colour system represents colours in an intuitiveway because it uses human colour perception as a basis. It is representedby the following set of colour features: I(ntensity), S(aturation), and H(ue).Because the I component is separated from the others, the space spannedby the HS components can be used for colour recognition independent oflight-levels. This is important for object recognition, since the top and bot-tom colour of a nearby ball can differ considerably in intensity, but both arestill red/orange.
Using HSI is too computationally intensive; fortunately a cube in HSImaps on a pie segment in YUV, and since the frame grabber device pro-duces YUV images it is computationally inexpensive to use. In the YUVcolour system Y corresponds to the luminance of a colour, and U and V cor-respond closely to the hue and saturation of a colour. In the Vision objectrecognition module, object colours are represented by their UV components.Object detection is based on these two components; luminance informationis discarded.
Size and position of these objects are estimated and this information ispassed on to the World model and to the Player skills. The latter is alsonotified when a large portion of an image is white, which usually indicatesthe robot is standing in front of a wall. The Player skills module can reactby taking appropriate measures to avoid hitting it.
Vision self-localization
As knowing your own position is crucial for constructing a globalworld model, the camera is also used for self-localization. Vision self-localization[16] (summarized in [30]) uses the lines on the field and thegoals. The self-localization mechanism involves a global and a local method.The global method first splits the image into multiple regions of interestand finds straight lines in each of these. The lines are matched to a model ofthe field, giving an estimate of the position. Because of the symmetry of thefield multiple position candidates are found. Multiple Hypothesis Trackingis then used to follow all the candidates over time, updating them for our
12 Functionality
own movement.The local method is used to verify these candidates and to correct for
changes. All the candidates are checked, verifying their heading and distanceto the goals and the overall result given to us by the local method. Theprocess is repeated until one candidate remains, which is used to update ourposition.Our self-localization mechanism requires the robot to move around be-
cause otherwise candidate self-positions cannot be discarded. For this reasonthe Team skills module is notified when we’ve lost our position. This occurswhen the confidence measure supplied with the position estimate is below acertain threshold. To give an idea of the performance of the self-localizationduring a game: for a total period of more than two hours our position wasknown only 44% of the time.
Motion
Driving is controlled by the Motion module which communicates motorcommands to the low-level processor of the Nomad. TheKickermodule con-trols the pneumatic kick mechanism used for shooting at goal. The Soundmodule plays sounds on request of other modules for entertaining and de-bugging purposes.
2.1.2 Tactics and strategy
On top of the lowest software level resides the tactical level, in which localcontrol of the robot as well the building and maintaining of a world modeltakes place. The strategy level of the software architecture is responsible forthe team strategy and action selection.
Player skills
The main reactive component of our architecture is the Player skills mod-ule [3]. It tries to fulfill the wishes of the Team skills module while at thesame time keeping in mind its other behaviours with a higher priority. Theseare the collision avoidance behaviour and the license to kill behaviour. Thecollision avoidance behaviour makes sure a robot does not run into obsta-cles such as robots and walls. If a robot has the ball and sees a large por-tion of the enemy goal the license to kill behaviour makes it shoot at it.These two reactive behaviours get their information directly from the Vi-sion object recognition system, while the non-reactive behaviours usuallyalso use the World model. These include simple actions like Goto(x, y, φ, v),ShootAtAngle(φ) and Seek(ball) but also more sophisticated actions likeDribbleToObject(enemyGoal) orGotoObject(ball) are available. The Playerskills module notifies the Team skills module when an action has been com-pleted or aborted, in which case it specifies the reason.
2.1 Software Architecture 13
Summary of available actions, in which x, y is a position, φ is an angle,v is a speed and object is either ball, yellowGoal or blueGoal:
• Turn(φ), rotate the robot around its axis until it reaches the desiredheading, relative to the center of the playing-field. Also angles relativeto the robot can be specified. The first is used when the robot knowsits position on the field, the second if it does not.
• TurnToObject(object), turn to face the object. The object parameterrefers to one of the objects stored in the world model.
• Shoot(), kick the ball straight ahead at maximum force.
• TurnShoot(φ), kick the ball at specified angle. This is accomplishedby driving while turning followed by a Shoot() action.
• Goto(x, y, φ, v), move to specified position while avoiding obstacles.Desired heading as well as desired speed at end point can be requested.Forward and backward motion is supported, but since the robot canonly detect obstacles in front of it driving backwards is not recom-mended during normal operation.
• GotoObject(object), if object is ball move toward the ball and try tocontrol it. The ball is considered “under control”, once it is inside theball holder. If object is one of the goals move toward it until the robotis one meter away from it (you usually don’t want it to actually driveacross the goal line).
• Seek(object), keep turning until the robot sees the requested object.
• Dribble(x, y, v), carefully drive to the requested position trying to keepcontrol over the ball. If the robot loses the ball don’t immediatelydeclare the action a failure but try to regain it. Dribbling with theball is difficult due to the shape restrictions and the limit of five motorcommands per second.
• DribbleToObject(object), dribble toward one of the goals. The Playerskills module keeps a memory of the relative position it last saw thegoals, in order to be able to find them again. This may seem super-fluous, nevertheless it is kept because the position and orientation ofthe robot are often unknown. The relative position of the objects inthe Player Skills module is kept on the basis of odometry positioninformation only, which is always available but not as accurate.
World model
To enable a distributed form of control and improve robustness, theWorldmodel [13] (summarized in [15]) is also distributed. Each of the robots in our
14 Functionality
team locally maintains a world model. This model consists of the dynamicobjects in the game (i.e. the robots and the ball), and the static objects (thegoals). Each of these objects has static features such as its colour and itssize, as well as more dynamic features such as its position, speed and relateduncertainties. Given the observations by the virtual sensor modules of thevarious objects in the game, it is up to the world model to combine theminto a view of the world as complete and accurate as possible.Since we want to construct an absolute model, which enables us to dis-
tribute it among our teammates (and thus facilitating cooperative teambehaviour), it is necessary that the robot knows its own position. Two sen-sors are used to estimate this position. The first is the odometry sensor,the second is the vision self localization. The odometry sensor continuouslykeeps track of the position of the robot. It will however, as explained before,lose its correctness after driving long distances or after collisions. So fromtime to time the vision self localization is used to reset the odometry posi-tion. It is up to the world model to combine the information of these twosensors in order to maintain a good estimate of the position. The intervalbetween two vision-based self-localization position updates is typically rel-atively large (usually approximately 30 seconds), therefore the world modelhas to keep a history of prior position estimates. This enables it to com-bine the vision-based estimate with the odometry information at the timethe vision-based self localization produces a new estimate. The new com-bined position estimate will be the weighted average of the two positions,where the weights are given by the respective uncertainty estimates. Thiswill result in a position shift from the original estimate, which can be usedto adjust all odometry positions received later, giving us an as accurate aspossible estimate of the position of the robot at that time.The other objects in the game are detected by the vision system. Each
observation will come with information about the shape and colour whichis observed (e.g. an orange ball or a black robot), and the position estimateof the observed object relative to the robot (camera). Given the robot’sself position, the world model will convert the robot-relative position of theobserved object to a position relative to the center of the field. Next it willtry to match the observation to any of the known objects in the world model.This is done by checking whether there is an object that matches the shapeof the observation within an uncertainty region. When an observation is thusmatched to an object, it will be inserted in the object’s observation history.Using the linear least squares algorithm the world model tries to fit a linearfunction through this list of observations. Extrapolating this linear function,enables us to do an accurate estimate of the position of the object at thattime while simultaneously filtering out noisy observations. It also enables usto estimate the speed and heading of the observed object.The world model keeps a list of the objects which are being tracked
(which are all objects which have been observed no longer than 4 seconds
2.1 Software Architecture 15
ago), and a list of objects which are known to be in the game but which aren’ttracked anymore. Once a non-tracked object is being perceived its status willbe changed from non-tracked to tracked, and tracking continues. This allowsthe world model to keep a model without any false or outdated informationwithout having to throw away potentially valuable future information.
Due to its limited field of view and the fact that parts of the field willbe occluded by the objects on them, the robots will often perceive only asmall part of the world. Maintaining a shared world model makes it possiblefor a robot to share information with the other robots in the team. Sharingthe local world models and combining these results in increased accuracyand completeness of the world models of all the robots in our team. A goodexample of this is the sharing of the position of the ball: when the ball isperceived by only one of the robots, all robots will be able to “perceive” theball through the shared world model, and reason about it.
One of the other features of the world model is the ball possession proto-col. When a robot detects that the ball is in its possession (i.e. the ball liesbetween its ball handlers) a notification is sent to the world model, whichwill record that the robot has the ball and will send a message to all otherrobots in the team, telling them the team has possession of the ball. Detect-ing whether the opponent team has possession of the ball is slightly hardersince our vision system does not enable us to detect whether the ball is inthe opponent’s ball handling mechanism. For now we assume an opponenthas ball possession if the ball has been within its reach for some time, andour team does not have the ball.
Team coordination
The advantage of a shared world model is that team coordination is greatlysimplified. The task of the Team skills is twofold: it coordinates team strat-egy, and it chooses the next action the Player skills module should execute.The task of the team coordination is to decide on a strategy. Three strate-gies are defined: attack, defend, and intercept, each of which depends onball possession information: if our team has possession of the ball, the teamwill attack, if the opponent team has ball possession a defensive strategy ischosen, if it no team is in ball possession - or it is unknown - the team willtry to intercept the ball.
Each strategy consists of a number of roles for an individual player tofulfil. The roles comprise: DefendGoal, PassiveDefend, ActiveDefend, Inter-ceptBall, AttackWithBall, AttackWithoutBall, and SelfLocalization. Utilityfunctions are used to compare the suitability of a robot to fulfil a certainrole to that of the suitability of others to fulfil that role. Utilities are basedon a subset of the world information. Three features are used: 1. The timethe robot expects it needs to reach the ball, 2. A position based role evalu-ation, 3. Whether or not a robot has ball possession. It is assumed that for
16 Functionality
each robot these information items are the same. Discrepancies in the worldmodel are disregarded.
All robots calculate the utilities that the other robots and they them-selves have for each role. The robots then send the utilities to each other.Each robot waits a while for the utilities of the other robots to arrive. Afterthis, role selection takes place. Role selection is not based on an electionmechanism. Instead, the first set of utilities to arrive from another robot isused by each robot to select a role. Since it is assumed the information basedon which the utilities are calculated is the same, it is assumed the utilitycalculations for each robot are equal. The utilities are exchanged neverthe-less, and utilities received from another robot have preference over utilitiesa robot has calculated itself. According to the behavioural design, this isbecause it introduces a level of redundancy.
If no utilities are received from another robot, a robot will use the utilitiesit has calculated itself. Once it is established what set of utilities will beused, the robot selects a role. To select its role, a robot compares the utilityscores for each role, in the order of the importance of each role to be fulfilled,starting with the most important role to be fulfilled. The role a robot selects,is the role which is the first role with the highest utility for it. In this wayit is assured that important roles are always fulfilled.
From the above it is possible to conclude that: On one hand, the roleselection is based on the assumption the world models in all robots are iden-tical and the results of the utility calculations on all robots should yield thesame results; and therefor each robot can decide its own role without furthercommunication. On the other hand all calculations are exchanged, and cal-culations received from other robots have preference over those calculatedby a robot itself for selecting a role.
This contradicts with the assumption that each robot can decide its ownrole without further communication. It is probably better to either chooseto make a decision based on local world model information alone (which isshared anyway) thereby ignoring inter-local world model discrepancies, orto choose for an election based decision process for distributing roles overthe robots.
Action selection
For each role a number of actions (see the discussion of the Player skillsmodule above) is enabled. To decide which action a robot should take, thecurrent state of the robot and its environment is evaluated. The state consistsof: whether the ball is in one of the goals, ball possession information, therole evaluation, and how well a robot is positioned in the field. In addition tothis information, a number of internal parameters are part of the state of arobot: the current distribution of roles among the field players, whether theself position is known or not, and the type of action the robot is currently
2.2 Communication 17
executing. The state is evaluated, and the action with the highest probabilityof success will be selected.
2.2 Communication
Communication between two modules is handled by a message passing sys-tem. The system is based on UDP and uses Linux kernel message queues. Ina message passing system, processes communicate by sending each othermessages. A message is an atomic unit with a message type and a stringof bits containing data. The message is sent from one module to anotherusing a method of delivery. In a message-based paradigm the abstraction isthat there are direct connections between modules that serve as conduitsfor messages. These conduits do not necessarily have to exist on a physicallevel. The routing for a message that travels from one module to anotheroccurs at hardware and lower software levels.
2.2.1 The Message Passing System
In the message passing system used for the robots, each module has a mes-sage queue. For every module, all incoming messages are stored in the mes-sage queue of the modules in order of arrival. When a module is ready toprocess a message, it will issue a request for the next message on its queueand process it. This process continues until all messages are processed or themodule terminates. Using message queues allows a module to send informa-tion when necessary without having to wait until the other party is ready toreceive. Without some form of buffering, modules would be subjected to ablocking wait if the other party isn’t ready. Such a situation can easily leadto a communication deadlock for the involved modules. The message passingsystem has been designed with shared memory capabilities in mind, but sofar none have been implemented. Both the intra robot communication aswell as the Inter robot communication is based on message passing forinformation exchange.
Communication between modules in different layers of the hierarchy canonly be initiated by the module which is in the higher layer. This ensures thatcontrol always resides with the higher module. In communication betweenmodules in the same hierarchical layer, each of the modules may initiatecommunication. Three different types of communication were defined in ourmessage passing system to accommodate for downward and upward commu-nication flows: Orders, Questions, and Triggered notifications. Orders areintended for the downward communication flow. Questions and Triggerednotifications should be used for the upward communication flow.
18 Functionality
Orders
Downward communication through the hierarchy is established by using theorder communication type. The order type is typically used when a moduleasks another module to perform a specific action. The order type is used tosend orders toward the actuators. For instance, Team skills action selectioncan send orders to the Player skills module (e.g. DribbleToObject(object)),which in turn can send orders to the Motion module. It should howevernot be possible for the Motion module to send an order to the Player skillsmodule (which resides on a higher level in the hierarchy).
Two types of communication are used for upward communication throughthe hierarchy: questions and triggered notifications.
Questions
If a higher level module is interested in information from a lower level mod-ule, the question type will be used to ask for the information. The lowerlevel module will answer the question. Upward communication through thehierarchy is less trivial than downward. If it is not allowed for lower levelmodules to initiate communication with higher level modules it is difficult touse event-like constructions for receiving sensor information. Clearly, ques-tions may be suitable to receive periodic information, but since they cannotbe initiated by lower level modules they cannot be used for event-like con-structions. Also, each Question generates one piece of information, so onepiece of information requires two messages: one question and one answer.This introduces double latency and bandwidth, which is no restriction to useit for sporadic or irregular information exchange. It is, however, for periodicinformation exchange. It would not make sense to use the question type forperiodic information, because the question would be repeated periodically,which is a waste of bandwidth. Another communication type used in theupward communication flow which more or less solves these issues is thetriggered notification type.
Triggered notifications
The triggered notification type can be seen as a single request for aparticular type of information from a higher level module to a lower levelmodule which honors the request by sending the information to the higherlevel module, either periodically or when new information is available. If thehigher level module is no longer interested in the type of information thelower level module sends, it simply requests the lower level module to stopsending.
The mechanism we use for the triggered notification communication type in
2.2 Communication 19
Odometry Motion Kicker Sound
Player skills
Vision objectrecognition
Vision selflocalization
World model
Action selectionTeam strategy
Q = QuestionO = OrderT = Triggered notification
Inte
r ro
bot c
omm
unic
atio
n
not specification compliant
Team skills
Q
Q
Q
QT
O
O QT
OQO
O
O
T
T
TT
T
Q
specification compliant
T
Q
Q QT
Figure 2.2: Communication details. The arrows represent the informationflow.
some aspects resembles a subscription mechanism. A subscription mech-anism is based upon the so-called push strategy: as soon as a producer ofdata has new data available it will publish the data so it is locally avail-able to subscribers, regardless whether a subscriber needs that particularinstance of data on that particular moment. When the moment arrives thesubscriber needs the data, it simply reads the data from its local buffer andcontinues processing. The main advantage is that when the data is neededit has already been transferred over the network, and is locally available tothe subscriber. An important difference between the triggered notificationand a true subscription mechanism is that a true subscription mechanismhas anonymous publishers/subscribers. In the mechanism we use the pub-lisher and subscriber know where the information comes from, respectivelygoes to. Therefore the architecture lacks the increased modularity whicharchitectures based upon a true subscription mechanism have.
2.2.2 Deviations from the communication specification
Given the types of communication and knowing communication can only beinitiated by the highest module of two communicating modules, it shouldbe easy to identify which type of communication is used for an arrow infigure 2.1. Unfortunately this is not the case. In figure 2.2, a more detailedpicture of the communication types used in the architecture is given, in which
20 Functionality
a distinction is made between the use of communication types whose usagecorresponds to the specification of the communication types as given in thedocumentation of the message system and the use of communication typeswhose usage does not correspond to it. Most of the non-compliant usage ofthe types, is the usage of the question type for periodic information, whichcan for instance be seen in communication between the World model andthe Team skills module2.A more serious type of deviation is the reverse of the initiation of com-
munication which occurs in the communication between the Vision self-localization and the World model module. The initiation of communicationby a lower module may seem very innocent, but in an architecture in whichcontrol is arranged hierarchically, it is very important control does residewith the higher module. If communication is initiated from below, the highermodule has no control over the information it receives, and therefore is (atleast partially) dependent on when and if the lower module is willing tosend information. It becomes unclear which of the two modules is in controlover the other. This is not a problem if the modules are part of the samehierarchical layer. If however two modules from different layers are involvedit should - metaphorically speaking - always be clear who is captain on theship.
2Note that the direction of the arrow represents the information flow. The question isinitiated by the Team skills module; the answer containing the requested information issent by the World model module.
Chapter 3
Coordination
This chapter discusses coordination languages and models, and distributedreactive systems. It will be shown that the facilities provided by coordinationmodels can conceptually be used to meet design requirements of distributedreactive systems in general and the RoboCup scenario in specific.
I will first introduce coordination languages and models, present someexamples of architectures incorporating explicit coordination models, afterwhich I will discuss distributed reactive systems with their respective de-sign issues, and present a number of examples of architectures incorporatingexplicit coordination models in reactive distributed systems.
3.1 Coordination Languages and Models
Classical views of concurrency in programming languages that are based onextensions of the sequential programming paradigm are ill-suited to exploitthe full potential of distributed systems. Instead this requires programmingmodels that explicitly deal with the concurrency of cooperation among po-tentially large numbers of active entities that distributed systems consistof.
A number of models and metaphors that explicitly deal with the con-currency of cooperation in distributed systems were designed in the secondhalf of the 80’s. The purpose of them being to (partially) abstract awayand encapsulate the details of communication and cooperation between anumber of entities performing some computation from the actual computa-tional activities performed by these entities. Examples of such models are theblackboard[22] model and the actor[1] model. The combination of thesemodels and metaphors resulted in the coordination paradigm.
22 Coordination
3.1.1 The Coordination Paradigm
The coordination paradigm considers programming a distributed systemto consist of two distinct activities: the actual computing part consisting of anumber of processes involved in manipulating data, and a coordination partresponsible for the communication and cooperation between these processes.
A number of coordination models and their associated programming lan-guages were designed and implemented. They share the same intent, namelyto provide a framework which enhances modularity, reuse of existing com-ponents, portability and language interoperability.
The coordination paradigm can be used to distinguish computationalconcerns of a distributed system from the communication ones. This allowsfor separate development of these two aspects of system design which leadsto increased modularity and thereby to better designs, reduction of devel-opment time, and lesser likelihood of errors.
Increased modularity also encourages reuse of existing components: sep-arate computational modules have separate functionality which can be easilyreused if they are not entangled by coordination constraints.
By separating the coordination component from the computational one,the coordination paradigm encourages language interoperability. The co-ordination component views the processes the computational componentsconsist of, as black boxes. The actual programming languages used to writecomputational code play no important role in setting up the coordinationsystem. Also, since the coordination component offers a homogeneous wayfor interprocess communication and abstracts away the machine-dependentdetails, coordination does not discourage the use of heterogeneous ensemblesof architectures.
To be able to use heterogeneous ensembles of architectures, most coor-dination models are portable. Different hardware platforms offer differentadvantages. The more hardware platforms are supported by a software ar-chitecture, the more universally applicable it is.
3.1.2 Coordination Models and Languages
A coordination model can be viewed as a triple (E,L,M), where E rep-resents the entities being coordinated, L the media used to coordinate theentities, andM the semantic framework the model adheres to [33]. A coor-dination language is the linguistic embodiment of a coordination model,offering facilities for controlling synchronization, communication, creation,and termination of computational activities [23].
Of the coordination models I discuss, only Linda and GAMMA haveentities being coordinated which are not entirely like application processes.For the others can be said the entities being coordinated are representedby application processes. In Linda the coordinated entities correspond to
3.2 Software Architectures Incorporating Coordination Models 23
the active stage of a tuple. In GAMMA a simple program is a {ReactionCondition, Action} pair and its execution involves replacing those elementsin a multiset satisfying the reaction condition by the products of the action.Linda and GAMMA will be discussed in more detail below.
3.1.3 Classification
Coordination models and languages can be classified into two main cate-gories: those that are data-driven, and those that are control-driven. Control-driven coordination models and languages are based upon the messagingparadigm.
In the messaging paradigm, the basic unit of information is a message.A message is an atomic unit with a message type and a string of bits con-taining the data. The message is sent directly from one process to another,using a guaranteed method of delivery. In a message-based paradigm, thetrue topology of the network is abstracted from, and any process can com-municate directly to another process within the system without necessarilybeing directly connected to it.
For the category of control-driven coordination models and languages,the changes in the coordination process are triggered by events signifyingchanges in the states of their coordinated processes. Members of this cate-gory are: PCL[28], Programmers Playground[14], and TOOLBUS[5].
Data-Driven coordination models and languages are based upon the in-formation paradigm.
In the information paradigm, the whole notion of connection has beenabstracted away. The connection between modules is through informationtypes. These may be represented as shared buffers between many modules oras information names which some modules produce and others consume. Ininformation based systems, producers of data tend not to care who consumestheir data, and consumers of data tend not to care who produces it.
For the category of data-driven coordination models and languages, thechange over time in the computation is driven by the types and propertiesof data involved in the coordination activities. Linda[2, 11], GAMMA[4],ETHNOS[25], NDDS[24], and SPLICE[6, 8] are examples of data-drivencoordination models.
3.2 Software Architectures Incorporating Coordi-
nation Models
A software architecture defines the organizational principle of a systemin terms of types of components and possible connections between thesecomponents. In addition, an architecture prescribes a set of design rules andconstraints governing the behaviour of components and their interaction. [7]
24 Coordination
In this section I will discuss two software architectures incorporating anexplicit coordination model: Linda and GAMMA, two coordination modelsbelonging to the data-driven category. Like most of the members of thiscategory they are developed around the notion of a shared data space. Ashared data space is a common, content-addressable data structure [26].All processes involved in computation can communicate among themselvesonly indirectly via this medium. Interprocess communication is done onlythrough the shared data space and the medium’s contents are mostly inde-pendent of the life history of the processes involved. Therefore shared dataspaces result in decoupling of processes in both space and time.
3.2.1 Linda
Linda[2, 11] is based upon the generative communication paradigm: iftwo processes want to exchange some data, then the sender generates a newdata object and places it in some shared data space from which the receivercan retrieve it. No process needs to know the identity of other processes, noris it required of all processes to be alive at the same time.The data objects are referred to as tuples, the shared data space is
known as tuple space. Besides tuples containing data - which are calledpassive tuples - the tuple space can also contain active tuples representingprocesses. Active tuples turn into passive tuples after the completion oftheir execution.
Linda consists of a set of simple coordination primitives:
• out(t) is a non-blocking primitive used to put a passive tuple t intuple space.
• in(t) is a blocking primitive which retrieves a passive tuple t fromtuple space.
• rd(t) is a blocking primitive which retrieves a copy of t from tuplespace (the original remains there).
• eval(p) is a non-blocking primitive which puts an active tuple p intuple space. A process that executes eval(p) will carry on executing inparallel with p, which will turn into a passive tuple once it completesexecution.
A number of additional primitives were introduced into the basic model:
• inp(t) which is the non-blocking variant of in(t).
• rdp(t) which is the non-blocking variant of rd(t).
inp(t) and rdp(t) will return FALSE when the desired tuple is notfound in the tuple space.
3.2 Software Architectures Incorporating Coordination Models 25
3.2.2 GAMMA1
GAMMA[4] is a coordination model based on multiset rewriting. Thebasic structure in multiset rewriting is a multiset, which can, unlikean ordinary set, contain multiple occurrences of the same element. Themultiset can be seen as the shared data space of GAMMA. The controlstructure associated with multisets is the Γ operator,
which is defined as follows:
Γ((R1, A1), ..., (Rm,Am))(M) =
if ∀ i ∈ [1,m] ∀ x1, ...xn ∈ M, eRi(x1, ..., xn)
then M
else2 let x1, ..., xn ∈ M, let i ∈ [1,m] such that Ri(x1, ..., xn) in
Γ((R1, A1), ..., (Rm,Am))((M − {x1, ..., xn}) +Ai(x1, ..., xn))
Where {...} represents multisets and (Ri,Ai) are closed functions specifyingreactions.
A process is a (Reaction Condition, Action) pair, and its execution in-volves replacing those elements in a multiset satisfying the reaction condi-tion by the products of the action. The result is obtained when no moresuch reactions can take place.
In the Γ operator, the effect of (Ri,Ai) on a multisetM is to replace inM a subset of elements {x1, ...,xn} such that Ri{x1, ...,xn} is true for theelements of Ai(x1, ...,xn). If the reaction condition holds for several disjointsubsets of M, the reactions can be carried out in parallel; this property iscalled locality.
The following example code implements a prime number generator:
prime numbers(N) = Γ((R,A))
({2, ..., N}) where
R(x, y) = multiple(x, y)
A(x, y) = {y}
It specifies that multiple elements should be removed from the multiset{2, ...,N}. The remaining multiset contains exactly the prime numbers lessthan N.
1This subsection is based on the discussion of GAMMA in [23].2 In the original discussion, the condition (incorrectly) was eRi(x1, ..., xn) instead of
Ri(x1, ..., xn).
26 Coordination
Although the operational behaviour of GAMMA is strictly implicit sincethe order of execution is by default completely parallel, practical use of ithas revealed a number of program schemes, which are referred to as tropes:
• Transmuter(C, f) applies the same operation f to all the elements ofthe multiset until no element satisfies the condition C.
• Reducer(C, f) reduces the size of the multiset by applying operationf to pairs of elements satisfying C.
• Optimiser(<, f1, f2,S) optimises the multiset according to some cri-terion expressed through the ordering between the functions f1 andf2, while preserving the structure S of the multiset.
• Expander(C, f1, f2) decomposes the elements of a multiset into acollection of basic values according to the condition C and by applyingf1 and f2 to each element.
• S(C) removes from the multiset all those elements satisfying C.
3.3 Distributed Reactive Systems
The roles of a reactive system include: (1) processing of measurementsobtained from the environment through sensing devices, (2) determinationof model parameters describing the environment, (3) tracking discrepanciesbetween the desired state and perceived state, (4) taking corrective action,and (5) informing the operator or team of operators about the current andpredicted state of affairs [8].
In distributed reactive systems the computation necessary to fulfilthese roles is distributed among several computational nodes which com-municate with one another through a communication network. Distributedreactive systems range from large embedded systems such as traffic man-agement and command and control systems to autonomous robotic soccerteams. Although their functional requirements differ, these systems share anumber of non-functional requirements.
3.3.1 Data Flow Types
Data flow type properties define characteristics such as how quickly the datamust be delivered (temporal constraints), whether or not the data gets toits destination (reliability), and what bandwidth constraints exist. Reactivesystems can have five types of data flow: signals, commands, status, eventsand requests [24].
Signals are typically rapid in nature, have short persistence, and canrequire high bandwidth. This is because it is more important to have the
3.3 Distributed Reactive Systems 27
most recent value than it is to get every value.Command data flow requireseach instruction in the sequence to be delivered reliably once and only once.Commands often are time critical. Status data flow requirements are typi-cally less rigorous, it usually persists for some time, it usually is not criticalto be delivered only once and may or may not be be time critical or reliable.Event data flow requirements vary: For example, an alarm response canhave strict requirements for time-critical and reliable delivery. Requestscan vary from one request to another. For some requests, the requester maynot want to wait until the request is fulfilled.
The requirements inherent to the data flow in distributed reactive sys-tems are part of the non-functional requirements.
3.3.2 Non-functional Requirements
Distributed reactive systems have non-functional requirements in com-mon, regarding temporal behaviour, robustness, availability, and maintain-ability.
Timeliness is one of these requirements resulting from the demand forthe system to decide on the correct action in time. It would - for instance- not do for a robot arm to be instructed after it smashed into the car itwas building. A real-time system is considered to function correctly only ifit returns the correct result within a given time.
A distributed system may suffer from various types of hardware failureranging from a lost message to a hard disk-crash. Robustness, is the ex-tent to which it is able to withstand such hardware failures. The ability tocontinue providing service proportional to the level of surviving hardware iscalled graceful degradation [27]. In contrast to systems based on grace-ful degradation, fault-tolerant systems are designed to fully mask failures.Fault-tolerance is usually achieved through hardware redundancy.
Maintainability is a requirement which arises from the desire to beable to adapt a distributed system to new functional requirements or toresolve problems which surface when the system has been designed andimplemented. For a maintainable system it should easily be possible to adaptit to new requirements, without seriously restructuring it.
The capability of a system to adapt to an increased service load is calledscalability. Systems have bounded resources and can become completelysaturated under increased load. Adding new resources might solve the prob-lem, but it might generate additional indirect load on other resources.
All previous non-functional requirements have to be met with availabilityconstraints in mind. A system meeting the availability requirement shouldmeet all previous requirements and be on-line no matter what happens.This means additional demands for, for instance maintainability: it should bepossible to replace and upgrade components of the system without switchingit off.
28 Coordination
3.3.3 Coordination in Distributed Reactive Systems
Architectures using explicit coordination models can help fulfilling the non-functional requirements inherent to distributed reactive systems. Coordi-nation models were developed for distributed systems. Additional require-ments for robustness, availability, maintainability, scalability and temporalbehaviour can only be partially solved in software, nevertheless a form ofarchitectural support to meet these requirements is desirable.
Data-driven coordination models offer a significant advantage overcontrol-driven coordination models: modules do not have to be aware ofeach other’s existence, which increases modularity and thereby loosens theconstraints placed on the design freedom by non-functional requirements.
A shared data space architecture is based upon an ideal situation wherenon-functional requirements need not to be taken into account. If one wantsto employ a shared data space architecture in distributed reactive systems,this architecture has to be refinened to meet the non-functional requirementsof distributed reactive systems.
Reactive systems based upon a shared data space architecture need tobe robust with respect to single points of failure. This means the shareddata space cannot be located at a single centralized hardware node. Bydistributing the shared data space over all nodes a single point of failure canbe avoided.
Robustness: Because processes are not aware of each other, they caneasily be distributed over the system. For instance: a failing software moduleor hardware node does not necessarily mean a complete breakdown of thesystem: the functionality of the failing modules can easily be taken over by(stand-by) processes in other parts of the system.
Maintainability: if functionality has to be added in a modular system inwhich the processes are not aware of each other, new modules can be addedwithout having to adapt other modules to accommodate them. New modulessimply consume data which is produced elsewhere and produce data whichcan be used by old modules and new modules alike. Upgrading modules canbe done in approximately the same way by creating a new module whichpublishes and consumes the same data types as its predecessor.
Temporal behaviour: a data-driven coordination model may utilize thesubscription paradigm. In this paradigm the publisher sends data tosubscribers as soon as it is available, often before the subscriber is interestedin a particular instance of data. A beneficial result from a performanceperspective is the that the delay between actual production and use of thedata depends more on the consuming application processes, and less on thecommunication network latency.
3.4 Software Architectures in Distributed Reactive Systems 29
3.4 Software Architectures in Distributed Reac-
tive Systems
This section describes three software architectures which are used in dis-tributed reactive systems. Each of these architectures comprises a shareddata space, applications and a communication network, and all of the archi-tectures are based upon the information paradigm.
3.4.1 ETHNOS
ETHNOS[25] is a programming environment for autonomous robotic sys-tems, used in the RoboCup by the Azzurra Robot Team. It consists of adistributed real-time operating system of the same name with an explicitcoordination model, a network communication protocol which extends UDPto support reliable data transmission, a programming interface and a set ofdevelopment tools.
The coordination model of the operating system is based upon the con-cept of expert, which is a concurrent agent responsible for a specific de-liberate behaviour. Experts are members of a tribe, each tribe is locatedin a separate network computer, which is called a village. All experts aredistributed over tribes depending on their respective computational tasks.
The functionality of the ETHNOS operating system performs threetasks: process creation, scheduling, and providing communication mecha-nisms. Three types of communication are distinguished, one of which is basedupon the information paradigm, and provides transparent inter expert com-munication - for experts in the same village as well as for experts in differentvillages - through the creation of, and access to, shared representations.
Scoping is a mechanism to provide scalability to an informationparadigm oriented architecture by defining the processes which are inter-ested in a specific type of information. In ETHNOS a scoping mechanism isprovided in the form of communication clubs. Three scopes are defined:1. an expert may publish in its village, 2. it may publish in its village in aspecific communication club, or 3. it may publish in all villages in all clubs.
The information paradigm and the notion of shared representations allowthe experts to be decoupled in execution. This makes it possible to establisha system which comprises dynamic reconfiguration, allowing experts tobe integrated into the system while the system is operational.
3.4.2 NDDS
NDDS[24] is a network middleware that implements the subscriptionparadigm with extensions to control flow semantics of the data. NDDS iscomposed of a run-time library, a database, and tasks. The application islinked with the library. The tasks perform all of the message addressing, and
30 Coordination
transporting. The architecture promotes a symmetric design: at the levelof the infrastructure all nodes are identical. Because there are no special orprivileged nodes, it is possible to build scalable systems without introducingsingle points of failure.
Each node in the architecture is composed of the following:
1. Applications are connected to the daemons that share the localdatabase.
2. Database stores cross-references, and updates information on all lo-cal and remote publications, subscriptions, client and servers based ondeclarations and refresh messages. A declaration message is sent whena publisher declares a publication, when a subscriber declares a sub-scription. A refresh message is sent when publications or subscriptionschange. These declarations as well as the refresh messages are storedin the database, and are used as references. For instance to locate apublications of a certain type.
3. Daemons are responsible for maintaining and refreshing the database,subscription management, and performing the message addressing.
NDDS is based upon RTPS which is an extension of the subscriptionparadigm for real-time applications. It provides:
• Delivery timing control: Real-time subscribers are concerned withtiming; for example when the data is delivered and how long it remainsvalid.
• Reliability control: Reliable delivery conflicts with deterministictiming. Each subscriber typically requires the ability to specify itsown reliability characteristics.
• Request-reply semantics: Complex real-time applications oftenhave one-time request for actions or data. These do not fit well intothe subscription semantics.
• Flexible delivery bandwidth: Typical real-time applications in-clude both real-time and non-real-time subscribers. Each subscribersbandwidth requirements - even for the same publication - can be dif-ferent.
• Fault-tolerance: Real-time applications often require “hot standby”publishers and/or subscribers.
• Thread priority awareness: Real-time communications often mustwork without affecting publisher or subscriber threads.
3.4 Software Architectures in Distributed Reactive Systems 31
• Graceful degradation: Each real-time logical data channel must beprotected from the others. That is, the slowdown or failure of one ofthe publishers should not affect a subscribers receipt of publicationsfrom other publishers.
• Robustness: The communication layer should not introduce anysingle-node points-of-failure to the application.
• Dynamic scalability: The lifetime of real-time distributed systemsoften exceeds the individual lifetime of any one publisher or subscriber.Publishers and subscribers need to be able to join and leave the appli-cation at any time.
• Efficiency: Real-time systems require efficient data collection and de-livery. Only minimal delays should be introduced into the critical data-transfer path.
In RTPS each publication is characterized by four parameters: topic,type, strength and persistence. The topic identifies the data-flow, the typedescribes the data format, the strength indicates the weight of a publisherrelative to other publishers, and the persistence indicates how long eachpublication issue is valid. When multiple publishers send the same publica-tion, the subscriber accepts the issue if its strength is greater than the lastreceived issue or if the persistence of the last issue has expired.Each subscription is also identified by a set of four parameters: topic,
type, minimum separation and deadline. Topic and type are again respec-tively the label that identifies the data flow and a description of the dataformat. Minimum separation defines a period after receiving an issue, dur-ing which no new issues are accepted for that subscription. The deadlinespecifies how long the subscriber is willing to wait for the next issue. Theminimum separation protects a slow subscriber against publishers that arepublishing too fast, the deadline provides a guaranteed wait time that can beused for the publisher to take appropriate action in case of communicationdelays.
RTPS provides a mechanism to customize the determinism versus thereliability trade-off for each subscription separately. This mechanism is sub-scriber driven; publishers simply send publication issues. To provide messagedelivery reliability, the publishers as well as the subscribers use buffers tostore issues. The publisher stores a history of the most recently sent issues,to enable a re-send when a subscriber misses an update. The subscriber usesthe buffer to cache the most recently received issues. This makes it possibleto have messages locally available when the subscriber is ready to processthem.
The subscription paradigm results in one-way communication from thepublisher to the subscriber. Real-time applications often need to send specific
32 Coordination
requests for data. Requests are inherently bidirectional, which is why theydo not match very well with the subscription paradigm. In NDDS this ismet by introducing the concept of named services. A service is identifiedby a name and separate types for the request parameters and reply data.An application can be a client, a server or both. When a client makes aservice request, it specifies the service by name and specifies a minimum waitand timeout for the reply. If during the minimum wait a number of servershave responded, the response from the server with the highest strength isaccepted. If no servers have responded during the wait, and the timeout hasnot yet expired, the first response received is accepted. When the timeouthas expired the client call returns with an error.
3.4.3 SPLICE
SPLICE[6, 8] is a software architecture designed for large-scale embed-ded systems that incorporates an explicit coordination model. The acronymstands for Subscription Paradigm for the Logical Interconnection of Con-current Engines.
The architecture is composed of four components:
1. Applications: Are autonomous, independent processes each of whichimplements part of the functionality of the system.
2. Shared Data Space: All communication between the applicationstakes place through a logically shared data space by reading and writ-ing elements to and from it.
3. Heralds: Every application interacts with exactly one herald. A heraldprovides storage capacity for the application as well as communicationfacilities for the application with the rest of the system. All heraldsare identical and require no a priori knowledge about applications ortheir communication requirements. Heralds communicate by means ofmessage passing.
4. Network: The network handles communication between heralds. Itshould support broadcasting, but should preferably also provide directaddressing of heralds.
Applications
Applications are active, concurrently executing processes that each imple-ment part of the system’s overall functionality. Besides process creation,there is no direct interaction between applications; all communication takesplace through a logically shared data space by writing and reading dataelements.
3.4 Software Architectures in Distributed Reactive Systems 33
SPLICE extends an existing programming language with coordinationprimitives for creating processes and for interacting with the shared dataspace. The application processes are created by applying one of these coor-dination primitives:
• create(f): creates a new application process from the executable filenamed f , and run it in parallel to the existing applications.
Shared Data Space
The shared data space in SPLICE is organized after the relational datamodel [12]. The basic relational data model3 is defined to consist of a com-bination of three components: 1. a collection of data object types, 2. a col-lection of general integrity rules, and 3. a collection of operators on the dataobject types which comply to the integrity rules. In SPLICE the object typesdefined as sorts, which consist of a name and a number of record fields.Each record field has a type, such as integer, real or string. Additionally,type constructors such as enumerated types, arrays, and nested records areprovided to build more complex types.The name provided with the sort makes it possible to distinguish between
different types of sorts. To enable further differentiation between data ele-ments of the same sort, identities are introduced in the form of key fields.Each element in the shared data space is uniquely determined by its sortand the value of its key fields.In addition to create(f), SPLICE provides three other coordination
primitives. They can be seen as part of the collection of operators on thedata object types of the shared data space:
• write(α, x): inserts an element x of sort α into the shared data space.If an element of sort α with the same key value already exists in theshared data space, then the existing element is replaced by x.
• read(α, q, t): reads an element x of sort α from the shared data space,satisfying query q. The query is formulated as a predicate over therecord fields of sort α. In case a matching element does not exist, theoperation blocks until either one becomes available or until timeoutt has expired. If the latter occurs, a timeout error is returned by theoperation. The timeout is an optional argument: if absent the readoperation simply blocks until a matching element becomes available.In case more than one matching element can be found, one is selectednon-deterministically.
• get(α, q, t): operates identically to the read operation, except that theelement returned from the shared data space becomes hidden from the
3Later referred to by Codd as “the Relational Model Version 1”.
34 Coordination
application’s view, that is, the same element cannot be read a secondtime by the application.
SPLICE does not provide an operation for globally deleting elementsfrom the shared data space. Instead, data can be removed implicitly usingan overwriting mechanism. This mechanism is typically used to update olddata with more recent values as the system’s environment evolves over time.
To allow distribution of the shared data space over a network of computersystems heralds were introduced.
Heralds
A herald embodies a local database for storing data elements, and processingfacilities for handling all communication needs of the application processes.Each application process interacts with exactly one herald. All heralds areidentical and need no prior information about either the application processor their communication requirements. Communication between heralds isestablished by a message passing system.
Messages between heralds are handled by the communication networkthat interconnects them. The network must support broadcasting, butpreferably should also support direct addressing of heralds, and multicast-ing. The interaction with heralds is transparent with respect to the shareddata space model: application processes continue to operate on a logicallyshared data space.
The heralds are passive servers of the application processes, but areactively involved in establishing and maintaining the required inter-heraldcommunication. The communication needs are derived dynamically by thecollection of heralds from the read and write operations that are issued bythe application processes.
The protocol that is used by the heralds to manage communication isbased upon a subscription paradigm which preserves the order in whichdata elements of the same sort have been written by an application. Thisprotocol makes sure the shared data space is selectively replicated across theheralds in the network, each herald contains only data of those sorts thatare actually required by the application it serves.
Data Categories
SPLICE provides a number of data sort categories. A data category spec-ifies the way a data sort is handled for communication and storage.
• context: A copy of the data will be stored in the data space, and canbe retrieved when a new process is started. Context data is typicallyused for automated initialization of processes. If a process has for some
3.5 Discussion 35
reason died, the context data should provide the information to allowa graceful restart of the process.
• periodic: Periodic or volatile data is the most commonly used datatype. Periodic data is presumed to be updated frequently, and is trans-ferred with an unreliable but fast protocol. The assumption is that ifan update is missed the previous or next update is good enough toreplace it (and the data is not resent).
• persistent: Persistent data is stored on persistent storage. This is toaccommodate system restart in situations like a total power failure.
Scoping
SPLICE provides a way to partition the data space by means of worlds.When an application publishes a sort this sort is published in a certain pre-specified world. A subscriber to this sort will only receive copies of this sortwhen it is subscribed to this sort in this world. If other instances of the samesort are produced in other worlds, they will not be received by an applicationsubscribed to the same sort in another world.This mechanism exists to provide scalability. Since information often has
a certain locality property, it is possible to publish it only within a contextwherein the data is used. This makes sure the transfer of this informationis not unnecessarily consuming bandwidth.Another way to use worlds is to make sure opponents (of a competitive
nature - for instance in a strategic simulation) do not receive informationthey should not be aware of. If for instance robot A and robot B are of differ-ent teams, it would be unwise for robot A to provide information regardingthe position of the ball to robot B. In this situation it would be beneficialto have separate worlds for each team of robots. Though this seems a safeway to separate the data spaces of two teams, it is always possible for robotB to subscribe to sorts of the team robot A plays in, therefore a maliciousteam can easily eavesdrop on communication of an opponent team. SPLICEsupports no security in this respect.It is also possible to publish a sort in more than one world, and subscribe
to sorts in more than one world, or all worlds. This makes it more easyto collect data across the entire system, for collecting statistical data, orgathering information for a user interface.
3.5 Discussion
When it is accepted that the facilities provided by coordination models canconceptually be used to meet design requirements of distributed reactivesystems, what coordination model would be most suitable and convenientto use in the RoboCup?
36 Coordination
It should be a data-driven coordination model. Data-driven coordinationmodels - as opposed to control-driven coordination models - are based on theinformation paradigm, which enables processes to cooperate in a distributedsystem without them actually having to be aware of the existence of the pro-cesses they are cooperating with. This is the result of using a shared dataspace, which enables to abstract away the notion of connection. Processesnot being aware of each other greatly simplifies design of the individual pro-cesses, since in the design stage the actual functionality a process representsonly depends on the process itself and the shared data space, not on otherprocesses.Of the software architectures for distributed reactive systems incorporat-
ing data-driven coordination models described, SPLICE is the most suitable.Other software architectures for distributed reactive systems incorporatingdata-driven coordination models, such as NDDS use explicit delivery timingcontrol mechanisms. While a certain amount of control over it is a goodthing to have, it is often hard to predict delivery timing demands at designtime. Therefore it is convenient this is handled transparently in SPLICE.SPLICE also offers the advantage that its data space is based on the
relational data model. The SPLICE data space can be addressed with queriesin an SQL-like fashion. Since most people are familiar with this concept thiswill have a positive influence on the learning curve. Aside from this, thenotion of primary key allows for a clear insight in data duplication whenwriting a data element.To simplify the design of a new robot soccer architecture based on
SPLICE, do we need the full functionality of SPLICE, or another data ori-ented real-time architecture incorporating an explicit coordination model,to be able to provide the functionality as is provided by the current imple-mentation of the robot soccer architecture?A new design should at least realize the functionality the current im-
plementation represents. However, as is shown in the following chapters, itis much easier to design a system based on SPLICE, than to develop thefeatures provided by SPLICE independently. Such as a data storage system,a robust communication system, fault tolerance, etc. Important features ofSPLICE such as decoupling processes to the extent SPLICE allows, are hardto implement if not by mimicking a system like it. In the end it would comedown to re-implementing SPLICE-like architectural support for RoboCup.
Chapter 4
Transition
This chapter discusses how to approach a SPLICE-based redesign based onthe current implementation of the Clockwork Orange robot soccer software.
4.1 Requirements
In the previous chapters, a number of issues have been described in devel-oping software for Clockwork Orange which can be translated into require-ments. In the subsections below a number of observations which should bekept in mind when developing a new design are discussed.
4.1.1 Structure
Communication in modules in different layers of the current module hierar-chy can only be initiated by a module which is higher in the layer hierarchy.This policy is a result from the desire to make modules with a higher capac-ity for “reasoning” have control over the initiation of an information flow.This allows them to decide on which information has priority in terms of pro-cessing, which is something a module with a lesser capacity of such shouldnot decide on. If we were to look at this from an information oriented per-spective however, this picture seems somewhat distorted. Information flowsare a question of supply and demand: the flow originates from difference inpotential. Of course, what is in demand is determined by the informationconsumer. But the choice of what data to receive should not reside with thepart of the system which is responsible for the implementation of the func-tionality of it, but should rather be the responsibility of the coordinationmodel, which should make sure information is available when it is neededfor processing.
Estimating the self-position of a robot is difficult, but absolutely essentialif observations made by one robot are to be used by another. It is howevernot possible to design a vision-based self-localization mechanism which re-
38 Transition
sults in a position estimate for which the confidence is one-hundred percentat all times. This means that if position estimates of objects observed bya robot through its camera, are translated to a representation shared bymore than one robot, an error is introduced. In the current implementa-tion, the Player skills module uses position observations which are based onsuch a shared representation. This is not always necessary since most of theactions as executed do not have to rely on information observed by otherrobots. On the contrary: local observations are not only without the coordi-nation translation error, but also do not suffer the latency originating in thecommunication system. Therefore it is better to use robot relative objectposition estimates in combination with as little position estimates made byother robots as possible for the action execution process.
The Player skills module consists of two distinct parts: a reactive be-haviour generation part, and an action execution part. The reactive be-haviour generation generates actions to be executed by the action execu-tion. The latter executes the actions of the reactive behaviour generation aswell as the actions generated by the more model-based behaviour genera-tion. The reactive behaviour generation and the action execution should beimplemented in separate processes.
The trend towards large modules should be discouraged in a new archi-tecture. The benefit of a number of small components each implementingpart of the functionality of a system, rather than a small number of verylarge components have been shown in - for instance - the UNIX family ofoperating systems. The current architecture exists of large modules, oftenimplementing several functional aspects of the system. A reorganization ofthese functional aspects inside the modules is therefore necessary. Preferablyeach functional component should correspond to a single SPLICE processin a new architecture. This may cost some additional effort when designing,but will probably simplify implementation and maintainance of the system.
4.1.2 Autonomy
There are situations in the current design in which distinct functional com-ponents are not implemented as single processes. To simplify design, imple-mentation and maintainance it is important to design the system as simpleas possible. Keeping the processes in the system small reduces the chanceof mistakes made during design and implementation simply because thecomplexity of small programs is usually lower than that of large programs.Also by mapping one distinct piece of functionality to one process, a processcan easily be replaced by another, which performs the same functionalitybut through a different approach, to assist in researching what method willperform best.
The self-location of a robot is known only for 44% of the time. In thecurrent architecture self-localization functionality is a part of the Vision
4.1 Requirements 39
module therefore it is hard to adapt. It would be easier if the self-localizationfunctionality would be implemented as an independent SPLICE process.This enables the possibility of implementing different methodologies, andallows for experimenting with different solutions.
From a robustness point of view, it is a good idea that modules are asindependent from each other as possible. Therefore the idea of maintainingautonomous software components as used in the current implementationshould also be applied in a new approach.
When new functionality has to be added to the system, it will usuallybe appended to an existing module even if it justifies the creation of a newsoftware component, because of the effort involved in creating a new module.This results in overly large, an unnecessarily complex modules.
The switch from a message oriented paradigm to an information orientedone will take more than a simple rewrite of the interface functions of themodules. The attitude of the modules towards sharing information in theexisting architecture can be described as “on a need to know basis only”. Ifa module indicates it needs information from another, then the informationwill be provided by the other, not sooner. This is not very convenient sinceat the time of a request, the requesting module usually already requiresthe information for processing. In an information oriented paradigm theseindications are not provided to the module sending information. Instead,information should be published into the shared data space as soon as it isavailable. Therefore the modules that produce information have to becomemore (pro-)active in committing information.
4.1.3 Communication
Although the current message passing system was designed with sharedmemory capabilities in mind, none have so far been implemented. Communi-cation via shared memory can be used to reduce the overhead for intra-robotcommunication.
The Team skills modules as well as the World model modules in a teamshare information which is relevant to more than one robot alone. This in-formation is shared by means of a broadcast. In other words: all robots onthe same subnet will receive this information. A competition between robotsusing the current implementation is hard, because the robots in opposingteams would share information. It would be impossible to build separatedistributed world models for two teams unless the opposing teams would beon different subnets. This is impractical since it would require two Breeze-COM base stations (see the hardware description in section 1.2) and it wouldrequire to modify the configurations of the robots in one of the teams.
The current message passing system is based on communication via UDPand uses Linux kernel message queues. While this is fast, the choice for analternative communication protocol which supports reliable communication
40 Transition
should be offered to the designers of the new system. Through a reliableprotocol it is possible to use communication patterns based on state changesrather than complete states. Sending complete states may be less prone tocommunication faults than sending state changes, but state changes are aresmaller in size than complete states and therefore have smaller bandwidthrequirements.
4.1.4 Addressing
The current implementation of the message passing system relies on commu-nication through so-called destination aliases. A destination alias consists ofan IP-address in combination with a module-id. This does not only make itvery hard to change the IP-address of the robots but also results in a verystatic architecture, from an adaptability as well as from a robustness pointof view.Runtime or dynamic reconfiguration is out of the question: if an agent
or module stops functioning, it is impossible for another agent respectivelymodule to take over its task, because the messages intended for it are stillsent to the alias of the non-functioning unit. Also important is the fact thatthe messages sent while the agent or module is restarting are thereby lost.In a simulation which simulates sensor readings of the robot and actuator
effects to the world which uses the modules as in a game - it is impossible tosimulate more than one robot on a single workstation because the routing ofthe message passing system relies on IP-addresses. Even if the workstationwould have four IP-addresses, there would be four world modules residingin it, which would have identical module identifiers.
4.2 Reuse
The reason for reusing software is clear: all functionality already imple-mented should preferably not be re-implemented. However, reusing softwarefrom the existing architecture is hard. Reusing a module in its entirety shouldnot be too difficult since each module comes with a well defined external in-terface. Since reusing an entire module is not always an option (see above),it is necessary to determine functional components on a sub-modular level.This is hard, since these components often do not exist in themselves butas intertwined parts of the overall functionality of the entire module, andtherefore do not have a well defined interface nor can they easily be identi-fied.Since the modules have over the years been designed by several people
with different approaches to intra module design, identifying functional com-ponents inside modules has to be approached differently for every module.Nevertheless the following more general notions can be applied to more thanone of them.
4.3 Information flows 41
All modules in the virtual device layer - the layer that provides an ab-straction to the underlying hardware - implement only one distinct func-tional aspect of the overall functionality: they provide an abstraction of anunderlying device driver for a specific sensor or actuator. The actuator mod-ules should simply accept actuator related specific SPLICE sorts instead ofactuator related specific message system orders, and the sensor modulesshould produce their information in SPLICE sorts instead of sending Trig-gered notifications.
Most modules consist of multiple concurrently executing programthreads. A number of the threads can - with some minor modifications -continue their lives in a new architecture. This occurs in the Player skillsmodule. It consists of two concurrently running threads which perform sep-arate functionality: one governs the reactive behaviour of the robot, theother executes actions provided by the Action selection part of the Teamskills module. The Team skills module also uses separate threads for theTeam strategy and the Action selection parts, but they are too large to beimplemented as only one functional component.
4.3 Information flows
Once it is recognized that it is possible to reuse components from the existingarchitecture but that some reorganization has to take place, it should beestablished what a new architecture should look like. Since the architectureis information oriented, viewing the architecture from an information-flowpoint of view is probably a good way to start.
In essence, the information flow in an autonomous system can be rep-resented by a feed-forward graph from the sensor side to the actuator side.Whirlpools resulting from reasoning and control mechanisms are representedby small feed-back loops in this graph. The information flow of a cooperatingrobot soccer team consists of four parallel information flows which connectin a number of places.
The information flow consists of information elements. They are repre-sented in SPLICE as data sorts. Information will be read from the envi-ronment by the sensors and produced by an application in the hardwareabstraction layer in the form of a data sort. This data sort will be consumedby another application which will produce another data sort of a differenttype. This alternation between processes and data communication will goon, meanwhile continuously manipulating information, until it arrives at theactuator side of the hardware abstraction layer. Finally, the information de-rived from the environment and enriched by several layers of processing, willbe transformed back into actions in the same environment.
All that has to be done to complete a new architecture, is identifyingwhat data elements should be used and which functional components from
42 Transition
the modules should represent the processes in it. This is shown in the nextchapter.
Chapter 5
Redesign
Chapter 2 discusses the existing software architecture and describes the func-tionality of its component modules. Chapter 3 discusses coordination modelsand software architectures incorporating an explicit coordination model, andthe advantages of using such architectures. Chapter 4 discusses how to ap-proach a SPLICE-based redesign based on the current implementation ofthe Clockwork Orange robot soccer software.This chapter will present a redesign of the RoboCup software using SPLICE.
5.1 Hardware Abstraction
The proposed architecture will build on the foundations of the existing ar-chitecture. The hardware abstraction layer represented by the virtual devicemodules will remain intact. The differences between these modules in thetwo architectures will be limited to using SPLICE for communication andcoordination, and a number of changes of name for processes to make theirnames lie closer to the nature of their functionality.
Three processes represent the sensor side of the hardware abstractionlayer: the Odometer process, Vision self localizer process, and the Vi-sion shape detector process, which are all depicted in figure 5.1. TheOdometer process produces a position and a heading of the robot in a coor-dinate system with an arbitrary origin. A position is defined as the distancefrom the origin of a 2-dimensional Cartesian grid, therefore an origin isneeded as a reference point. The Vision self localizer process also producesa position and heading of the robot, only in a coordinate system with anorigin at the center of the field. The Vision shape detector produces shapesresulting from camera image segmentation. A shape consists of a colour anda size, besides that it is observed at a certain time an at a certain position.The position of the shapes is in a coordinate system with the origin at thecenter of the robot the camera is mounted on.
Three processes have been described, and already we have three coor-
44 Redesign
odometer
odometry self position odometry self heading
self position estimator vision shape detector
shape:position (robot)
shape:colour
shape:size
shape:observation time
shape position estimator
vision self localizer
vision self position vision self heading
self:position (arbitrary)
self:heading (arbitrary)
self:position (field)
self:heading (field)
self:mode
object:colour
object:size
object:observation time
object:observer
object:position (robot)
object:position (arbitrary)
object:position (field)
Figure 5.1: The Odometer process, Vision self localizer process, and the Vi-sion shape detector process, representing the sensor side of the hardwareabstraction layer. Based on the sensor information, the Self position estima-tor process and Shape position estimator process respectively estimate theposition of the robot, and the position of shapes perceived by the robot. (Anenlargement of this figure can be found in Appendix B on page 64).
dinate systems to take into consideration: the coordinate system with anarbitrary origin, the coordinate system with the center of the field as ori-gin, and the coordinate system with the center of the robot as origin. Thefirst two are used for the position of the robot, and the latter for objectsperceived by a robot. To be able to share objects perceived by a robot withthe other players, it is necessary to represent the position of the objects in acommon coordinate system. This coordinate system is the field coordinatesystem. A translation of the shape positions in robot coordinates to fieldcoordinates is therefore necessary. For this translation a robot should knowits own position in the field.
5.1.1 Self Position Estimation
The Vision self localizer process produces a reasonably accurate robot posi-tion in field coordinates. The frequency it produces these estimates however,is very low. During a typical game, approximately once every 30 seconds anestimate is produced. To bridge the gap between the estimates producedby the Vision self localizer process, the position produced by the Odometerprocess can be used. When a self position update is received from vision,the offset between the odometer position and the field position can be deter-
5.2 Objects 45
mined. In the time between the vision field position updates, the odometerposition in combination with the offset can be used to estimate the currentposition in field coordinates. The systematic error introduced by the odome-ter (see section 2.1.1) will not be a problem in this set-up, the odometer willhowever get confused if a collision occurs. Fortunately, the effects of thiscan be minimized by doing a sanity check on the estimated self position,by means of which can be determined whether it is probably correct or not.This check consists of taking the self position and heading, and a segmentedcamera image. If due to the position and orientation of the robot, the cam-era should be facing the yellow goal and it is not - or vice versa - the selfposition is most probably wrong.
Another approach is to use a so-called particle filter to estimate the selfposition of a robot. In this case the Vision Self Localizer process produces anumber of estimates and the confidence in them on a more frequent basis.The estimates are used to update the particle filter relative to confidencein them. Meanwhile the Odometer process also produces position updates,additionally these can be used to shift the particles in the particle filterto provide intermediate updates. The particles in the particle filter usuallyconverge to one or more clusters. The essence of extracting an estimatedposition from it comes down to picking the right cluster and taking thecenter of gravity of that cluster as a measure for the self position in particlespace, after which this can be translated to field coordinates. One of theadvantages of using a particle filter is the memory function it provides, youcould say it filters samples in the temporal domain.
Estimating the position an the heading of the robot, while taking intoconsideration the points mentioned above, is the responsibility of the Selfposition estimator process (shown in figure 5.1). The Self position esti-mator process produces the self position and heading in field coordinatesand the self-mode. The self-mode can be either shared or local, respectivelydepending on whether the self position is known or unknown. The mode isused to determine whether objects observed by a robot may be shared withother robots, since there is no sense in sharing objects for which the fieldposition is unknown. Besides the self position and heading in field coordi-nates, the Self position estimator process also produces the self position inodometry coordinates (which have an arbitrary - but constant - origin). Thisis used when the position of the robot in field coordinates is unknown, butit is still necessary to know the relative robot position at different times. Forinstance to be able to determine the trajectory of objects.
5.2 Objects
The Shape position estimator process (also shown in figure 5.1) con-sumes the self position, self-mode and shapes, and determines the position
46 Redesign
object tracker
local tracked objectlocal trajectory
shared tracked object shared trajectory
object:colour
object:size
object:observation time
object:observer
object:position (robot)
object:position (arbitrary)
object:position (field)
object:current position (robot)
object:current position (arbitrary)
object:current position (field)
object:current velocity
object:current accelleration
object identifier object parameter estimator
trajectory migrator
ball player #goal #
ball property determinator player property determinatorgoal property determinator
self:mode
self:position (arbitrary)
self:position (field)
ball:possession
ball:in goal
ball:in view
ball:time to reach
goal #:in view
goal #:angle to
player #:guessed role
player #:current position (field)
Figure 5.2: The Object tracker process, Trajectory migrator process, Objectidentifier process, Object parameter estimator process, Player property de-terminator process, Ball property determinator process, and Goal propertydeterminator process. Objects are tracked, identified, and parameters andobject specific properties are determined. (An enlargement of this figure canbe found in Appendix B on page 65).
of a shape in field-coordinates or odometry-coordinates depending on themode. Once the position of a shape is known, it is called an object. Likeshapes, objects comprise a colour, a size, an observation time, and a posi-tion in camera coordinates. Additional properties an object has, are: an ob-server, a position in field coordinates, or a position in odometry-coordinates.All objects for which the position in field coordinates is known are sharedbetween the robots. The observer identification is provided for robots tomake a distinction between accurate position information (locally observed)and inaccurate position information (observed by other robots). The posi-tion in field coordinates of the objects, is used to make an estimation of thetrajectory an object is pursuing.
5.2.1 Trajectories
It is impossible for observations to be tracked unless their position is knownin a coordinate system which is not related to the robot. Since the robotmoves around, the origin of its (robot relative) coordinate system moveswith it. Observations made by the robot in robot coordinates, can onlybe correlated if the coordinate system their positions are represented in, isbased on a fixed origin as compared to the positions of the observations.
5.2 Objects 47
Once shapes have become objects their positions are represented in such acoordinate system, and therefore it is possible to keep track of shapes thatprobably represent the same object. This is the task of the Object trackerprocess (shown in figure 5.2). Based upon the objects produced by the Shapeposition estimator process it produces trajectories and tracked objects.Tracked objects and trajectories are codependent: Tracked objects cannotexist without a trajectory, and a trajectory is based on position information,and thus can not exist without objects. Trajectories are basically a list ofsimilar objects which are alike in colour and shape, but differ in their positionand observation time.
Depending on whether the position of an object is known in field coor-dinates or in odometry-coordinates respectively shared or local trajectoriesand tracked objects are maintained. Since shared tracked objects have anestimated position in field coordinates, it is possible to share them betweenthe team players. Because of this, all objects observed by a robot when theself position in field coordinates is known, can also be observed by otherrobots. If the self position is unknown it is impossible to use information ob-served by other robots, and therefore it is equally impossible to share localobservations with other robots. Nevertheless it is necessary to track objectsfor the robot to still be able to play the game, if this is not possible as ateam player then as an individual player.
5.2.2 Parameters
Once the trajectory of an object is known it is possible to estimate objectparameters such as the heading, and the velocity, as well as the currentposition. The position of the last observation of a tracked object is notnecessarily the current position. It is possible to extrapolate on trajectoryinformation to estimate the current position of a tracked object. Like thecurrent position, the (current) heading of an object can be estimated thisway; this is necessary because the heading of an object cannot be deducedfrom a camera image as perceived through the vision shape detector. Objectparameters are produced by the Object parameter estimator process.Object parameters are updated continuously, and added to the propertiesof tracked objects.
5.2.3 Identification
For processes making decisions regarding the behaviour of the robot, trackedobjects alone are not sufficient. Behaviour is defined in terms of namedobjects such as ball, goal, and player. Therefore a process should exist whichidentifies objects and names them. It is possible to identify objects for whatthey are, based on the trajectory information of an object. This is the task ofthe Object identifier process, that produces named objects. It identifies
48 Redesign
and names static objects such as the goals or the corner poles, as well asdynamic objects like the players or the ball, based on the properties of atracked object like colour, shape, and trajectory. The colour property ismost useful to identify the ball, which is always orange/red, or to make adistinction between players of our team and the opponent team, which weardifferently coloured shirts. To make a distinction between the individualplayers of the teams based on vision alone is difficult since there are noeasily observable visual distinctions between players in one team. To identifyindividual players, it is necessary to use trajectory information.
5.2.4 Properties
To support behavioural processes further properties specific to a named ob-ject should be determined. For each named object there is a specific processwhich determines properties which are specific to the named object and areof a higher abstraction level. For instance, rather than speaking in terms ofthe position of a ball, the Ball property determinator process producesinformation like whether the ball is in possession of our team or in posses-sion of the opponent team, whether the ball is in one of the goals, and whattime it takes to reach the ball. The Goal property determinator pro-cess produces information regarding to whether a particular goal is in viewand what angle it has to the robot. The Player property determinatorproduces information regarding the players on the field. All information ofa high level of abstraction regarding the named objects is produced in thislayer. If it is necessary for the behavioural processes to know whether a par-ticular player is in view, and what angle it has to the robot, it is easy toextend the Player property determinator process or to add a new processwhich fulfils this function.
5.3 Team Coordination
The behaviour of the robots can be divided into two levels: team coordina-tion, which should result in coherent team behaviour; and individual actionselection, which determines the behaviour of the robot within terms of therole the robot performs in the team strategy. The team strategy is entirelydetermined by possession of the ball. Three strategies are possible: Attack,Defend, and Intercept, this is depicted in figure 5.4. The process respon-sible for determining the current team strategy is the Strategist process,which is depicted in figure 5.3. It consumes ball possession information andproduces the team strategy. If a robot detects a change in ball possession,the robot can decide on a new strategy which is determined according tothe finite state machine depicted in figure 5.4, if this is the case, the newstrategy will be made known to all players.
5.3 Team Coordination 49
attractor, repeller, and slope calculator
attractor repeller slope
possible role
position based role evaluator
role selector
role utility calculator
self:position (field)
role:position based evaluation
possible role determinator
strategy
selected role
possible role:utility
ball:in view
ball:time to reach
ball:possession
strategist
self:mode
Figure 5.3: The Strategist process, the Possible role determinator process,the Attractor, repeller and slope calculator process, the Position based roleevaluator process, the Role utility calculator process, and the Role selectorprocess. A strategy is decided on, for which the possible roles are determined.For these roles a utility is calculated. Role utilities of different robots arecompared, and a role is selected based on the priority of the role and itsutility. (An enlargement of this figure can be found in Appendix B on page66).
5.3.1 Roles
Each strategy defines a number of roles, for a robot to fulfil. To make surethe most important roles are always performed, the roles are ranked, rel-ative to their importance in the current team strategy. The roles include:DefendGoal, PassiveDefend, ActiveDefend, InterceptBall, Attack-WithBall, AttackWithoutBall, and Selflocalization. If for instance thestrategy is Defend, roles like ActiveDefend will have priority over Intercept-Ball and AttackWithBall. Possible roles for the selected strategy are pro-duced by the Possible role determinator process. This process consumesthe strategy and determines the roles to be fulfilled, based on the table asshown in table 5.1. A number of roles are defined in terms of an area on thefield. If a robot performs a defensive role, it should most of the time stayon its own half of the play field. For a robot fulfilling an offensive role theopposite is true and it should maintain a position on the opponent half ofthe field for most of the time. For a robot to determine on which side of thefield it is, it is necessary for it to know its self position in field coordinates.
50 Redesign
InterceptDefend
Attack
we gain ball
nobody/unknown
they gain ball
they keep ball
they gain ballwe gain ball
gets ball
we keep ball
nobody/unknownkeeps ball
nobody/unknown gets ball
Figure 5.4: Finite state machine to determine the next team behavior. [29]
Strategy #1 #2 #3 #4
Attack DefendGoal AttackWithBall PassiveDefend AttackWithoutBall
Defend DefendGoal ActiveDefend PassiveDefend ActiveDefend
Intercept DefendGoal InterceptBall PassiveDefend InterceptBall
Table 5.1: Distribution of roles associated with each team strategy. [29]
5.3 Team Coordination 51
Nonetheless a role like AttackWithBall can also be performed by a robotwhich doesn’t know its self position, since it involves moving/shooting theball into the enemy goal, which makes it a ball-oriented role rather than aposition-oriented role.
A robot selects its role based on the possible roles as produced by thePossible role determinator, and a utility for each of these roles for the robotitself as well as for the utilities other robots have calculated. This is the taskof the Role selector process. The utility of each role is calculated for eachrobot, and compared. The robot which has the highest utility for a certainrole may fulfil this role. If a robot has the highest utility for more than onerole, the one with the highest rank will be selected. This makes sure moreimportant roles are assigned before roles of lesser importance.
5.3.2 Utilities
Utilities are determined on basis of the possible roles, a position based roleevaluation, whether the ball is in view or not, the time to reach the ball, ballpossession information, and whether the current position in field coordinatesis known in combination with a static set of formulae which quantify theseinto a measure of suitability for the robot to perform each role. Once thusquantified, the utilities cannot1 be used to compare which role is best for arobot to perform, they can however be used to compare the suitability ofrobots to perform a role between the robots. Utilities for possible roles areproduced by the Role utility calculator.
The position based role evaluation is used by the Role utility calculator tocalculate the utilities of position-oriented roles. For each role deemed possibleby the Possible role determinator, a position based evaluation is made. Thistask is performed by the Position based role evaluator process. Asidefrom the possible roles and the self position of the robot in field coordinatesit also consumes attractors, repeller, and the slope. The general flavour of arole determines the slope. For an attacker it should be more desirable to beclose to the opponents goal than to be near its own goal, for a defender thisis vice versa. The attractors and repellers respectively are objects or regionswhose position it is desirable for a robot to be at, and objects or regionswhose position it is not desirable for a robot to be at. The opponent goalfor instance has a positive influence on an attacker. A defender should notcross the half-way line, therefore the opponent half of the field is markedas repeller. The attractors, repellers and the slope for the a possible roleand the self position in field coordinates are combined into a position basedrole evaluation. The attractors, repellers, and slopes are determined by theAttractor, repeller, and slope calculator process.
1This is the result of a design choice made for the behavioural design: the utilities ofdifferent roles are based on different norms, and therefore should not be compared.
52 Redesign
tactical self positioning evaluator
self:tactical positioning
self:position (field)
action simulator world state composer
simulated world statesimulated world states other robots
ball:in goal
ball:possession
reactive behaviour
role:position based evaluation
selected roleself:mode
action:currently executing
player #:current position (field)
action simulator
action:simulated world
action evaluator
action:reward
action:probability of success
action utility calculator
action:utility
estimated selected action other players
action selector
action:selected
action:parameters
action executer
reflex action:selected
reflex action:parameters
license to shootgoal #:in view
goal #:angle to
move:distance
move:angle
move:timeout
movekick:
pressurekick
play:soundfile
play:volume
play
ball goal # player #
motion controller kicker sound player
Figure 5.5: The Strategic self positioning evaluator process, the Action simu-lator world state composer process, the Action simulator process, the Actionevaluator process, the Action utility calculator process, the Action selectorprocess, the Reactive behaviour process, the Action executor process; andthe actuator side of the hardware abstraction layer: the Motion controllerprocess, the Kicker process, and the Sound player process. Based on theselected role, all actions available to the role are simulated and evaluated.Based on utilities of the actions and the probable actions other players willtake, an action is selected and executed. The Reactive behaviour processmonitors the current world state, and publishes reflex actions accordingly.(An enlargement of this figure can be found in Appendix B on page 67).
If for a robot its position in field coordinates is unknown, roles which areposition-oriented rather than ball-oriented, cannot be fulfilled by it. Also aposition based role evaluation cannot be made. In this case the utilities forthe field-oriented roles will all be very low. Utilities regarding ball orientedroles are expressed in terms of the distance and angle to the ball, whichare measures independent of the self position of the robot. If it is unknownwhere the ball is, the same applies for ball-oriented roles.
5.4 Action Selection and Reactive Behaviour
Based on the selected role, a robot can decide on its next action to perform.A number of actions are considered: Turn,Move, Dribble, Shoot, Seek,andChase, of which for each role a subset is defined. An action is selected by
5.5 SPLICE mapping 53
simulating all actions on the current world state. For this purpose a model ofthe world is generated by the Action simulator world state composerprocess as depicted in figure 5.5, which consumes world state information,and produces a world state for a robot and its team-mates. The actionsimulator generates an estimated world state after action execution for allactions. The simulation itself is fairly trivial, it for instance simply assumesthat actions always succeed. Nevertheless the simulator predicts the nextstate with sufficient accuracy to estimate the probability of success of theaction. The simulator is incorporated in the Action simulator process.Based on the simulated worlds an evaluation of success of actions can bemade by the Action evaluator process. The evaluation results in a rewardand a probability of success for an action. The Action utility calculatorprocess determines the utility of the actions of this robot as well as predictsthe most likely action taken by its team players. Based on the utilities ofthe actions in combination with the actions the team players most probablymake, an action is selected by the Action selector process.
Actions produced by the Action selector process are consumed by theAction executer process, where they are translated to commands in termsof the actuator side of the hardware abstraction layer. Move commands forthe Motion controller process, kick commands for the Kicker process,and play commands for the Sound player process. The action executoruses robot relative information only, thereby ensuring that - even if the selfposition in field-coordinates is unknown - action execution can be performedanyhow.
Besides actions produced by the Action selector process, reflex actionsproduced by the Reactive behaviour process are consumed by the Actionexecutor process. The Reactive behaviour process continuously monitors theworld for certain conditions to become true, and if they are - produces reflexactions. If for instance the ball is in possession of the robot, the angle tothe opponent goal is correct, and the opponent goal is wide open, a reflexaction (shoot) will be produced, which has priority over normal actions asproduced by the Action selector process.
5.5 SPLICE mapping
In the previous chapter (section 4.3) it was mentioned that all that has tobe done to complete a new architecture, was identifying what data elementsshould be used and which functional components from the modules shouldrepresent the processes in it. This has been shown above. Now only oneimportant step has yet to be taken: the components of the functional designas presented above should be translated in terms of SPLICE facilities.
54 Redesign
5.5.1 Data categories
All data sorts have to be categorized into splice data categories (see subsec-tion 3.4.3). Most data sorts can be categorized as volatile, it may howeverbe beneficial if some sorts related to the team behaviour are decided to becontext data. Team strategy is something that will not change very rapidlyover time. Therefore, if a robot or a number of (relevant) processes have tobe restarted during a game, the team strategy or at least the role the robotshould perform for it should be restored. Use of the persistent data categoryis not necessary for the presented architecture, although a future design canuse it for - for instance - storing learned behavioural parameters betweentwo game halves.
5.5.2 Worlds
SPLICE has a scoping mechanism based on Worlds (see subsection 3.4.3).Worlds exist in order to provide a notion of locality in the shared dataspace, in order to profit from the locality property usually found in data.This allows for partitioning the data space into separate sections. The figuresdepicting the design discussed above: figure 5.1, 5.2, 5.3, and 5.5, on page44, 46, 49, and 52 respectively, depict the data sorts as blue, green or violetovals.
Blue ovals are used for sorts which are produced in another figure. Greenovals are sorts that are produced in the Robot n world, which is the worldprocesses of robot n use for exchanging local information; such as a shootaction. Violet ovals are sorts that are produced in theTeam m world, whichis used by processes of robots in team m to exchange information, relevantto more than one player in the team; such as strategy and role utility sorts.In a simulation of two competing teams, each with four robots, a total of2 + 4 + 4 = 10 worlds are used to partition the data space. If more thanone simulation of such a game is run, it may be useful to introduce separateworlds for different simulations: each simulation publishing in a Simulationp world. If two simulations are run, each simulation running two teams, atotal of 2 + 10 + 10 = 22 worlds are used to partition the data space.
Although it is possible to add worlds beyond the point of a simulationlevel, it is difficult to imagine what use they would have since it is alwayspossible to use the so-called default world which is used for publicationsand subscriptions if no world is specified by the process. On a different note:it is possible to use worlds for all kinds of purposes. For instance, worlds canbe used to publish statistics. It is possible for a process to subscribe to alldata in a specific world, therefore a single process can be used to gather allstatistical data produced.
5.5 SPLICE mapping 55
5.5.3 Processes
The mapping of processes as presented in the previous sections on SPLICEprocesses is one to one. This results in a system with 29 active processeswhen operating; significantly more than the 9 processes in the existing im-plementation. Since there are O(n2) possible relations between n modules,instead of the mere 72 relations the modules in the existing implementationcan have, some 812 possible relations have to be taken into account. It istrue, however, that only a subset of all relations have to be considered sincenot every processes will be connected to every other process; the increasein level of complexity in terms of relations between processes will be of thesame magnitude as the increase in number of processes.The new processes themselves may be less complex, and easier to un-
derstand than the existing ones, but this means the complexity has beenmoved from the processes into the infrastructure. In other words: the inher-ent complexity of the system has not disappeared, but has been moved tothe information interdependencies of the new processes. The infrastructuremust now be able to handle these communication dependencies.This is where SPLICE comes in: based on the information of what sorts
each process consumes (requires) and produces (probably required by an-other process), it is possible for SPLICE to work out the communicationdetails for every pair of processes and transfer the data in such a way theinformation (often) has been transferred before it is actually needed for pro-cessing.
Chapter 6
Conclusion
Based on the research performed, this thesis presented a design of a softwarearchitecture for Clockwork Orange based on SPLICE. Although I have notimplemented this design nor evaluated the implementation, a summary ofthe most important conclusions I have been able to draw can be found below.
• Documentation of the functional components is essential for future
generations of students and other participants of the RoboCup project.
It is very nice to have an architectural overview of a system, but with-out a clear description of the internal components, every new partici-pant in the project will basically have to reinvent the functionality ofa component module when starting to work on it.
• To a certain extent it is possible to reuse software components from the
current implementation. With some minor modifications, componentsfrom the lower levels of abstraction can be reused in a SPLICE basedarchitecture. For the higher levels of abstraction this is not the case.It probably requires less effort to rebuild them than to reuse thesecomponents in their entirety.
• Using a coordination model - especially if it is data-oriented - for dis-
tributed systems design results in a flexible software architecture. Dueto the high degree of modularity in such an architecture, it becomesmore accessible, robust, maintainable, adaptable, extendable, and scal-able. This makes it easier to focus on the functional aspects, ratherthan on the coordination aspects of the system.
• The trend towards large processes should be discouraged in a new ar-
chitecture. The benefit of a number of small components each imple-menting part of the functionality of a system, rather than a smallnumber of very large components have been shown in - for instance- the UNIX family of operating systems. Preferably each functional
58 Conclusion
component should correspond to a single SPLICE process in a new ar-chitecture. This may cost some additional effort when designing, butwill simplify implementation and maintainance of the system.
• To simplify design, implementation and maintainance it is important
to keep the structure of the system as simple as possible. A way torealize this is by mapping one distinct piece of functionality to exactlyone process. A process can then for instance easily be replaced byanother which produces the same data sorts. This allows for greatflexibility in terms of maintainance and researching what method willperform best for a certain subproblem.
Implementation and evaluation of a SPLICE based RoboCup software areFuture Work.
6.1 Future Work
At the moment of writing a so-called Progress project with the title “Aframework for maintaining a shared world model in dynamic environmentsbetween differentiated embedded systems and allowing interacting with hu-man supervisors” is in progress.The RoboCup project will be one of the environments used for test-
ing concepts for this project. Solutions to interesting research problems re-garding distributed systems, world modelling and user interaction will beimplemented on the Clockwork Orange robot team. SPLICE most likelywill provide the infrastructure on top of which these systems will be imple-mented. It is possible that these implementations will form the basis of anew SPLICE based RoboCup software architecture for Clockwork Orange.Meanwhile, the RoboCup software implementation as it currently exists,
is being used for research by students in Delft and Amsterdam. This willprobably continue to be the case until the time arrives when it is possibleto use enough software components from the Progress project for RoboCupthat a SPLICE based architecture can be developed. If it is shown that thisimplementation performs equally or better than the current implementation(in terms of research and won games), it will probably replace the currentimplementation.
Appendix A:
Middle-Size League Rules of
Conduct1
The league in which the Dutch robot soccer team Clockwork Orange par-ticipated is the middle-size league. Unlike the Sony four legged league, theteams in the middle-sized league are free to choose the type of robot, sensorsand actuators. However there are some restrictions. The robot may not havea configuration in which its projection on the floor does not fit in a 60×60cmsquare. A robot should also have a configuration (with all its actuators re-tracted) in which its projection on the floor fits into a 50×50cm square. Therobot may not be any higher than 80cm but should be at least 30cm (so it islarge enough to be perceived by other robots). The ball handling mechanismshould be built in such a way that it is always possible for an opponent tosteal the ball. Therefore a ball handling mechanism may not include the ballfor more then 1/3 the size of the ball (see figure 6.1). It also is prohibitedto fix the ball to the body by using some kind of ball holding device. Theserules also make it more challenging to let the robot turn and dribble withthe ball. The robots should all be completely black and are supposed to wearsome kind of marker which is either magenta or cyan, depending on the teamthe robot is in. This makes it possible for the robots and the audience to seewhich team the robot is in. The robots should also have numbers on themmaking it possible for the referee to tell them apart. The markers should bevisible from all sides, have a minimum size of 10 centimeters and must bepositioned above 30 centimeters high and below 60 centimeters. Before thestart of each game the team leaders and the referee will decide which teamwill play with which colour.
The ball that is used is the standard orange FIFA size 5 ball. The field isgreen and may vary in size between 8 and 10 meters in length and between4 and 7 meters in width. The lines are white and closely resemble the lineson a human soccer field. There is a line in the middle of the field, with a dotin the middle, from which the kickoff is taken, with a 1 meter wide circle
1This text is taken from a section in the master thesis of Matthijs Spaan [29].
60 Appendix A: Middle-Size League Rules of Conduct
Robot
Ball
Figure 6.1: The ball handler rule
Figure 6.2: The sizes and lines of a robot soccer field
around it, which must be empty apart from the taker of the kickoff and theball when starting a game. There are penalty dots on which the ball willbe positioned during a penalty shoot-out and there is a goal-area on eitherside of the field. The field is surrounded by a wall, so the ball can’t leave thefield. There are two 2-meter wide goals, a blue one and a yellow one, makingit possible for the robots to distinguish their own goal from the opponentgoal by colour.
The rules of the game are comparable to but not completely the sameas those of human soccer. If all robots would stay in line in front of theirown goal it would be impossible for the opponent to score a goal. Thereforeonly one robot in each team, which must be designated as goal keeper, maypermanently stay in the team’s own goal-area. Any other robot may notstay in its own goal-area for more then 5 seconds. Also only one robot at
61
a time may enter the opponent’s goal area and may stay there for no morethen 10 seconds and is only allowed there if the ball is also in the goal area.This should prevent obstruction of the opponents goal keeper and by doingthat scoring goals in a unguarded goal. As in human soccer, a robot willreceive a yellow card when charging an opponent. The game is stopped andthe opponent gets a free kick. When a robot receives a second yellow cardthis is considered a blue card and the robot must be removed from the gameuntil the next game restart. If a robot receives a fourth yellow card this isconsidered a red card and the robot must leave the field for the remainder ofthe game. Other rules, present in human soccer, like corner kicks, throw-insand the off side rule don’t apply to RoboCup at this moment. The durationof a game is 20 minutes, divided in two halves of each 10 minutes. During a15 minute half-time break teams can if necessary change the batteries andfix their robots. The complete FIFA and RoboCup rules can be found in[21].
Appendix B:
Figures
This appendix contains enlargements of figures placed in the main text whichcontain text hardly readable due to its size. Layout considerations preventedme to enlarge the images in the main text, therefore enlargements are placedin this appendix. All figures are cross-referenced to the place they can befound in the main text.
64 Appendix B: Figures
odometer
odometry self position odometry self heading
self position estimator vision shape detector
shape:position (robot)
shape:colour
shape:size
shape:observation time
shape position estimator
vision self localizer
vision self position vision self heading
self:position (arbitrary)
self:heading (arbitrary)
self:position (field)
self:heading (field)
self:mode
object:colour
object:size
object:observation time
object:observer
object:position (robot)
object:position (arbitrary)
object:position (field)
Figure 6.3: This figure is an enlargement of figure 5.1 on page 44.
65
object tracker
local tracked objectlocal trajectory
shared tracked object shared trajectory
object:colour
object:size
object:observation time
object:observer
object:position (robot)
object:position (arbitrary)
object:position (field)
object:current position (robot)
object:current position (arbitrary)
object:current position (field)
object:current velocity
object:current accelleration
object identifier object parameter estimator
trajectory migrator
ball player #goal #
ball property determinator player property determinatorgoal property determinator
self:mode
self:position (arbitrary)
self:position (field)
ball:possession
ball:in goal
ball:in view
ball:time to reach
goal #:in view
goal #:angle to
player #:guessed role
player #:current position (field)
Figure 6.4: This figure is an enlargement of figure 5.2 on page 46.
66 Appendix B: Figures
attractor, repeller, and slope calculator
attractor repeller slope
possible role
position based role evaluator
role selector
role utility calculator
self:position (field)
role:position based evaluation
possible role determinator
strategy
selected role
possible role:utility
ball:in view
ball:time to reach
ball:possession
strategist
self:mode
Figure 6.5: This figure is an enlargement of figure 5.3 on page 49.
67
tactical self positioning evaluator
self:tactical positioning
self:position (field)
action simulator world state composer
simulated world statesimulated world states other robots
ball:in goal
ball:possession
reactive behaviour
role:position based evaluation
selected roleself:mode
action:currently executing
player #:current position (field)
action simulator
action:simulated world
action evaluator
action:reward
action:probability of success
action utility calculator
action:utility
estimated selected action other players
action selector
action:selected
action:parameters
action executer
reflex action:selected
reflex action:parameters
license to shootgoal #:in view
goal #:angle to
move:distance
move:angle
move:timeout
movekick:
pressurekick
play:soundfile
play:volume
play
ball goal # player #
motion controller kicker sound player
Figure 6.6: This figure is an enlargement of figure 5.5 on page 52.
Bibliography
[1] Agha, G. ACTORS: A Model of Concurrent Computation in Dis-tributed Systems. MIT Press, Cambridge, Mass., 1986.
[2] Ahuja, S., Carriero, N., and Gelernter, D. Linda and friends.IEEE Computer 19, 8 (August 1986), 26–34.
[3] Altewischer, W. Implementation of robot soccer player skills us-ing vision based motion. Master’s thesis, Pattern Recognition Group,Department of Applied Physics, Faculty of Applied Sciences, Delft Uni-versity of Technology, 2001.
[4] Banatre, J., and Metayer, D. L. Gamma and the chemical reactionmodel: Ten years after. In Coordination programming: mechanisms,models and semantics, J. Andreoli, C. Hankin, and D. L. Metayer, Eds.Imperial College Press, 1996, pp. 3–41.
[5] Bergstra, J., and Klint, P. The ToolBus Coordination Architec-ture. In Proceedings of the First International Conference COORDI-NATION (Cesena, Italy, 1996) (Cesena, Italy, 1996), P. Ciancarini andC. Hankin, Eds., vol. 1061, Springer-Verlag, Berlin, pp. 75–88.
[6] Boasson, M. Control systems software. IEEE Trans. on AutomaticControl 38, 7 (July 1993), 1094–1106.
[7] Boasson, M. Software architecture special issue (guest editor). IEEESoftware, 11 (November 1995).
[8] Boasson, M. Architectural support for integration in distributed re-active systems. COMPSAC Workshop (2001).
[9] Borenstein, J., and Feng, L. Measurement and correction ofsystemetic odometry errors in mobile robots. IEEE Transactions onRobotics and Automation 5 (Oct. 1996).
[10] Brooks, R. Achieving artificial intelligence through building robots.MIT AI Lab Memo 899 (1986).
70 BIBLIOGRAPHY
[11] Carriero, N., and Gelernter, D. Linda in context. Communica-tions of the ACM 32, 4 (April 1989), 444–458.
[12] Codd, E. F. A Relational Model for Large Shared Data Banks. Com-munications of the ACM 13, 6 (June 1970), 377–387.
[13] Donkervoort, R. Evaluation of the worldmodule of clockwork or-ange, the dutch robot soccer team. Master’s thesis, Intelligent Au-tonomous Systems Group, Faculty of Science, University of Amsterdam,2002.
[14] Goldman, K. The Programmers’ Playground: I/O Abstraction forUser-Configurable Distributed Applications. IEEE Trans. on SoftwareEng. 21, 9 (September 1995), 735–746.
[15] Groen, F., Roodhart, J., Spaan, M., Donkervoort, R., and
Vlassis, N. A distributed world model for robot soccer that supportsthe development of team skills. In Proceedings of the 13th Belgian-DutchConference on Artificial Intelligence (BNAIC’01) (2001).
[16] Jong de, F., Caarls, J., Bartelds, R., and Jonker, P. P. Atwo-tiered approach to self-localization. In RoboCup 2001 (to appear),A. Birk, S. Coradeschi, and S. Tadokoro, Eds., Springer-Verlag.
[17] Jonker, P. P. On the architecture of autonomously soccer playingrobots. Tech. rep., Applied Physics Department, Delft University ofTechnology, 2000.
[18] Jonker, P. P., Caarls, J., and Bokhove, W. Fast and accuraterobot vision for vision-based motion. In RoboCup 2000: Robot SoccerWorld Cup IV (2001), P. Stone, T. Balch, and G. Kraetzschmar, Eds.,vol. 2019 of Lecture Notes in Artificial Intelligence, Springer-Verlag.
[19] Jonker, P. P., van Geest, W., and Groen, F. C. A. The Dutchteam. In RoboCup 2000: Robot Soccer World Cup IV (2001), P. Stone,T. Balch, and G. Kraetzschmar, Eds., vol. 2019 of Lecture Notes inArtificial Intelligence, Springer-Verlag.
[20] Kitano, H., Asada, M., Kuniyoshi, Y., Noda, I., Osawa, E., and
Matsubara, H. Robocup: A challenge problem for AI. AI MagazineSpring (1997), 73–85.
[21] Kraetzschmar, G. RoboCup middle size robot league (F-2000)rules and regulations for RoboCup-2001 in Seattle. http://smart.
informatik.uni-ulm.de/ROBOCUP/f2000/rules01/rules2001.html,2001.
BIBLIOGRAPHY 71
[22] Nii, H. P. Blackboard systems. In The Handbook of Artificial Intelli-gence, vol. 4. Addison-Wesley, 1989, pp. 1–82.
[23] Papadopoulos, G., and Arbab, F. Coordination models and lan-guages. Advances in Computers 46 (1998).
[24] Parado-Castellote, G., Schneider, S., and Hamilton, M.
Ndds: The real-time publish subscribe middleware. In IEEE Work-shop on Middleware for Distributed Real-Time Systems and Services(San Francisco, CA, 1997). 1997, pp. 222–232.
[25] Piaggio, M., Sgorbissa, A., and Zaccaria, R. Programming realtime distributed multiple robotic systems. Advanced Robotics, The In-ternational Journal of the Robotics Society of Japan 12, 8 (1998).
[26] Roman, G.-C., and Cunningham, H. C. Mixed programmingmethaphors in a shared dataspace model of concurrency. IEEE Trans-actions on Software Engineering 16, 12 (December 1990), 1361–1373.
[27] Silberschatz, A., and Galvin, P. B. Operating System Concepts.Addison Wesley Longman, Inc., 1998.
[28] Sommerville, I., and Dean, G. Pcl: A language for modelling evolv-ing system architectures. IEEE Software Engineering Journal (March1996), 111–121.
[29] Spaan, M. Team play among soccer robots. Master’s thesis, Intel-ligent Autonomous Systems Group, Faculty of Science, University ofAmsterdam, 2001.
[30] Spaan, M., Wiering, M., Bartelds, R., Donkervoort, R.,
Jonker, P. P., and Groen, F. C. A. Clockwork Orange: The DutchRoboSoccer Team. In RoboCup 2001 (to appear), A. Birk, S. Corade-schi, and S. Tadokoro, Eds., Springer-Verlag.
[31] Tanenbaum, A. S. Computer Networks (International Edition).Prentice-Hall, Inc., 1996.
[32] Visser, A., Lagerberg, J., van Inge, A., and Herzberger, L. O.
Organisation and Design of Autonomous Systems. Faculty of Mathe-matics, Computer Science Physics and Astronomy, University of Ams-terdam, August 1999.
[33] Wegner, P. Coordination as constrained interactions. In Proceed-ings of the First International Conference COORDINATION (Cesena,Italy, 1996) (Berlin, Germany, 1996), P. Ciancarini and C. Hankin,Eds., vol. 1061, Springer-Verlag.
Index
action, 52
Chase, 52
Dribble, 52
Move, 52
Seek, 52
Shoot, 52
Turn, 52
Action evaluator process, 53
Action executer process, 53
Action selector process, 53
Action simulator process, 53
Action simulator world state com-poser process, 53
Action utility calculator process,53
active tuples, 24
ActiveDefend roles, 49
actor model, 21
AI, xiii
API, xiii
Applications, 30, 32
Attack strategy, 48
AttackWithBall roles, 49
AttackWithoutBall roles, 49
Attractor, repeller, and slope cal-culator process, 51
autonomous agent, 5
ball holder, 4
Ball property determinator pro-cess, 48
blackboard model, 21
bumper ring, 4
camera, 3
Chase action, 52
Clockwork Orange, 2
colour space
HSI, xiii, 11
YUV, 11
Command data flow type, 27
communication clubs, 29
communication type
order, 18
question, 18
triggered notification, 18
context data category, 34
control-driven coordination mod-els and languages, 23
coordination language, 22
coordination model, 22
ETHNOS, xiii, 23, 29
GAMMA, xiii, 23, 25
Linda, 23, 24
NDDS, xiii, 23, 29
PCL, xiii, 23
Programmers Playground, 23
SPLICE, xiii, 23, 32
TOOLBUS, 23
coordination models and lan-guages
control-driven, 23
data-driven, 23
coordination paradigm, 22
Daemons, 30
data category, 34
context, 34
periodic, 35
persistent, 35
data flow type
Command, 27
INDEX 73
Event, 27
Requests, 27
Signals, 26
Status, 27
data-driven coordination modelsand languages, 23
Database, 30
default world, 54
Defend strategy, 48
DefendGoal roles, 49
Delivery timing control, 30
distributed reactive systems, 26
distributed system, 5
Dribble action, 52
dynamic reconfiguration non-functional requirement,29
Dynamic scalability non-functional requirement,31
Efficiency, 31
ETHNOS coordination model,xiii, 23, 29
Event data flow type, 27
expert, 29
expert robot competition league, 1
Fault-tolerance non-functional re-quirement, 30
fault-tolerant non-functional re-quirement, 27
Flexible delivery bandwidth, 30
frame grabber, 4
GAMMA coordination model, xiii,23, 25
generative communicationparadigm, 24
Goal property determinator pro-cess, 48
Graceful degradation non-functional requirement,31
graceful degradation non-functional requirement,27
Heralds, 32high level computer, 4HSI colour space, xiii, 11
IEEE, xiiiinformation paradigm, 23Inter robot communication, 17Intercept strategy, 48InterceptBall roles, 49IP, xiii
key fields, 33kick device, 4Kicker module, 12Kicker process, 53
leagueexpert robot competition, 1middle-size real robot, 2real robot, 1software robot, 1
Linda coordination model, 23, 24locality, 25low level motor board, 4
Maintainability non-functional re-quirement, 27
message, 17message passing system, 17messaging paradigm, 23middle-size real robot league, 2model
actor, 21blackboard, 21
moduleKicker, 12Motion, 12Odometry, 10Player skills, 12Sound, 12Team skills, 15
74 INDEX
Vision object recognition, 11Vision self-localization, 11World model, 13
Motion controller process, 53Motion module, 12motors, 4Move action, 52multiset, 25
name, 33named objects, 47NDDS coordination model, xiii,
23, 29Network, 32Nomad Scouts, 2non-functional requirement
dynamic reconfiguration, 29Dynamic scalability, 31Fault-tolerance, 30fault-tolerant, 27Graceful degradation, 31graceful degradation, 27Maintainability, 27Robustness, 27, 31scalability, 27Timeliness, 27
non-functional requirements, 27
object, 46Object identifier process, 47Object parameter estimator pro-
cess, 47Object tracker process, 47Odometer process, 43Odometry module, 10order communication type, 18
PAL, xiiiparticle filter, 45passive tuples, 24PassiveDefend roles, 49PCL coordination model, xiii, 23periodic data category, 35persistent data category, 35Pioneer 2, 2
Player property determinator pro-cess, 48
Player skills module, 12
playing field, 2
Position based role evaluator pro-cess, 51
Possible role determinator pro-cess, 49
process
Action evaluator, 53
Action executer, 53
Action selector, 53
Action simulator, 53
Action simulator world statecomposer, 53
Action utility calculator, 53
Attractor, repeller, and slopecalculator, 51
Ball property determinator,48
Goal property determinator,48
Kicker, 53
Motion controller, 53
Object identifier, 47
Object parameter estimator,47
Object tracker, 47
Odometer, 43
Player property determinator,48
Position based role evaluator,51
Possible role determinator, 49
Reactive behaviour, 53
Role selector, 51
Role utility calculator, 51
Self position estimator, 45
Shape position estimator, 45
Sound player, 53
Strategist, 48
Vision self localizer, 43
Vision shape detector, 43
INDEX 75
Programmers Playground coordi-nation model, 23
Progress, 58
question communication type, 18
Reactive behaviour process, 53reactive system, 26real robot league, 1record fields, 33reflex actions, 53relational data model, 33Reliability control, 30Request-reply semantics, 30Requests data flow type, 27RoboCup, 1Robot n world, 54Robustness non-functional re-
quirement, 27, 31Role selector process, 51Role utility calculator process, 51roles, 49
ActiveDefend, 49AttackWithBall, 49AttackWithoutBall, 49DefendGoal, 49InterceptBall, 49PassiveDefend, 49Selflocalization, 49
RTPS, xiii, 30
scalability non-functional require-ment, 27
Scoping, 29Seek action, 52Self position estimator process, 45Selflocalization roles, 49Shape position estimator process,
45shapes, 43Shared Data Space, 32shared data space, 24Shoot action, 52Signals data flow type, 26Simulation p world, 54
soccer server, 1software architecture, 5, 23software robot league, 1sonars, 4sorts, 33Sound module, 12Sound player process, 53sound system, 4SPLICE coordination model, xiii,
23, 32SQL, xiiiStatus data flow type, 27Strategist process, 48strategy, 48
Attack, 48Defend, 48Intercept, 48
subscription mechanism, 19subscription paradigm, 28symmetric design, 30
Team m world, 54Team skills module, 15Thread priority awareness, 30Timeliness non-functional require-
ment, 27TOOLBUS coordination model,
23tracked objects, 47trajectories, 47tribe, 29triggered notification communica-
tion type, 18tropes, 26tuple space, 24tuples, 24
active, 24passive, 24
Turn action, 52
UDP, xiii
village, 29virtual actuators, 9, 10virtual sensors, 9, 10
76 INDEX
Vision object recognition module,11
Vision self localizer process, 43Vision self-localization module, 11Vision shape detector process, 43
wireless communication, 4World model module, 13worlds, 35
YUV colour space, 11
Recommended
