a mission plan specification language for behaviour …tsotsos/homepage of john...
TRANSCRIPT
A MISSION PLAN SPECIFICATION LANGUAGE FORBEHAVIOUR-BASED ROBOTS
by
Albert Louis Rothenstein
A thesis submitted in conformity with the requirements
for the degree of Master of Science
Graduate Department of Computer Science
University of Toronto
© Copyright by Albert L. Rothenstein 2002
ii
AbstractA Mission Plan Specification Language For Behaviour-Based Robots
Albert Louis Rothenstein
Master of Science
Graduate Department of Computer Science
University of Toronto
2002
The S*{ XE "S*" } architecture [Tsotsos{ XE "Tsotsos" } 1997,
Tsotsos 1995b, Tsotsos 1996] was proposed as a solution to the problem of
integrating reactive and deliberative functionality in robot control. We
describe the S*{ XE "S*" } robot control architecture, its theoretical
foundation, salient points and major contributions.
In the context of S*{ XE "S*" }, we have implemented a mission
specification language that provides support for task decomposition,
synchronization and execution monitoring, seeking to complete the
specification of the proposed language and to realize an implementation of the
overall mechanism, to demonstrate the process of converting a mission
description into a behaviour network{ XE "network" }, and executing the
mission on a simulated mobile robot. Examples are presented.
iii
Acknowledgements
Many, many thanks go out to...
Professor John K. Tsotsos, my thesis advisor, who gave me guidance andsupport throughout the entire thesis process. And, most importantly, for hisfriendship.
John K. Tsotsos and Sven Dickinson, for helping me transform a heap ofwords into a thesis. And then reading it.
Michael Jenkin, Wolfgang Stürzlinger, and George Tourlakis, for being therewith advice when I needed it most.
Andrei Rotenstein, for being a great partner in this research, and for beingthere when I needed to vent my frustration.
Clark Verbrugge for all the discussions and advice over the years. Fromformal grammars to casting one’s body parts in plaster, nothing was off limits.
IBM Canada and Crestech, for supporting my studies and research financially.
My parents, without whom I would never have enjoyed so many opportunities,for their love and encouragement.
And last but not least Gabi, for the very special person she is. And for theincredible amount of patience she had with me. This one’s for you.
iv
TABLE OF CONTENTS
Chapter 1 Introduction ......................................................................................... 11.1 Background..............................................................................................21.2 S* Framework........................................................................................ 10
Chapter 2 Mobile Robot Simulator ...................................................................162.1 System Background...............................................................................162.2 Implementation......................................................................................17
Chapter 3. Mission Specification Language .....................................................243.1 The Language ........................................................................................25
3.1.1 Sequences Of Behaviours ............................................................ 263.1.2 Temporal Connectors ................................................................... 263.1.3 Grouping Constructs - Phase ....................................................... 293.1.4 Grouping Constructs – While-Ensure.......................................... 313.1.5 Behaviour Parameters .................................................................. 35
3.2 Language As Implemented....................................................................39Chapter 4. Behaviour Networks ........................................................................41
4.1 Behaviour Interaction ............................................................................414.1.1 Competitive Methods ................................................................... 424.1.2 Cooperative Methods ................................................................... 434.1.3 Discussion..................................................................................... 434.1.4 Proposed Solution ........................................................................ 49
4.2 Extended Behaviours.............................................................................514.2.1 The Pure Behaviour...................................................................... 534.2.2 Behaviour Parameters .................................................................. 544.2.3 Daemons ....................................................................................... 554.2.4 Behaviour Status........................................................................... 56
4.3 Nested Ensure Clauses...........................................................................564.4 Behaviour Life-Cycle ............................................................................574.5 Example .................................................................................................59
Chapter 5 Implementation and Experimental Results ......................................625.1 Parsing: From Missions To Intermediate Representations ..................63
5.1.1 Behaviour Parameters – Numeric Parameters............................. 635.1.2 Behaviour Parameters – Representation Names As Parameters. 655.1.3 Behaviour Parameters – Symbolic Parameters ........................... 655.1.4 Behaviour Network Node Descriptors ........................................ 665.1.5 Parameters In Node Descriptors .................................................. 695.1.6 Networks Of Node Descriptors.................................................... 69
5.2 From Intermediate Representations To Networks Of Behaviours.......725.2.1 Behaviour Parameters .................................................................. 735.2.2 Start/End Pseudo-Behaviours ...................................................... 735.2.3 Compatible Ensure Clause Behaviours ....................................... 745.2.4 Prohibited Ensure Clause Behaviours ......................................... 75
5.3 Building the Complete Behaviour Network .........................................755.4 Behaviour Life-Cycle – The Implementation.......................................76
v
5.5 Experimental Results.............................................................................785.5.1 Behaviour-Based Target Tracking............................................... 795.5.2 Behaviour-Based Target Tracking with Mutual Inhibition ........ 825.5.3 Mission-Based Target Tracking – Three Examples.................... 845.5.4 Integrating Deliberative and Reactive Behaviours...................... 925.5.5 The Ensure Clause........................................................................ 94
Chapter 6 Conclusions and Future Work ..........................................................996.1 Conclusions............................................................................................996.2 Future Work.........................................................................................102
Appendix A – Mission Syntax.........................................................................106Appendix B – UML Diagrams ........................................................................114Bibliography.....................................................................................................119
vi
LIST OF FIGURES
Figure 1. Decomposition of robot operational software into horizontalstructures ....................................................................................................3
Figure 2. Decomposition of robot operational software into vertical structures .5Figure 3. The SMPA-W cycle.............................................................................13Figure 4. Image processing steps: top: BW camera images, middle: Laplacian
images, bottom: disparity map used by navigation module...................19Figure 5. Simulator screenshot: 1a, 1b - views from left and right cameras, 2 -
collision sensor, 3 - proximity sensor, 4 - bird's eye view, with whitelines indicating the field of view of the cameras....................................21
Figure 6. The temporal connectors between behaviours ....................................28Figure 7. Structure of a behaviour envelope.......................................................53Figure 8. Simple Example - bump-and-turn (dotted line indicates inhibition) .60Figure 9. Graph of behaviour network node descriptors. B – behaviours, R –
representations, V – numeric values, S/E – Start/End pseudo-nodes, W– while-ensure pseudo-nodes, P – phase pseudo-nodes. Numberedboxes are described in the text. ...............................................................71
Figure 10. Simple example - target tracking and analysis..................................80Figure 11. Simple example - target tracking and analysis with collisions (dotted
line indicates inhibition)..........................................................................83Figure 12. Intermediate representation for target tracking mission ...................86Figure 13. Behaviour network for target tracking mission.................................87Figure 14. Behaviour network for target tracking mission - multiple instances of
a behaviour...............................................................................................88Figure 15. Behaviour network for target tracking mission with parameters .....91Figure 16. Inegrating reactive and deliberative behaviours ...............................93Figure 17. Intermediate network for mission with an ensure behaviour ...........95Figure 18. Behaviour network - ensure behaviour .............................................97Figure 19. Intermediate network for mission with ensure boolean predicate....98Figure 20. UML - The simulated robot.............................................................115Figure 21. UML - Behaviour envelope classes.................................................116Figure 22. UML - Representations used in the examples.................................117Figure 23. UML - Controllers ...........................................................................118
1
Chapter 1 Introduction
This project is part of an effort to implement and validate the S*{ XE"S*" } proposal presented in [Tsotsos{ XE "Tsotsos" } 1997], with a particularfocus on presenting an implementation of the mission specification languageintroduced there.
First, background information will be presented, placing S* in thecontext of past and current robotics research, followed by a description of theS*{ XE "S*" } robot control architecture, its theoretical foundation, salientpoints and major contributions and claims. A brief overview of representativecurrent research with similar focus helps put this research in context andhighlights the relevance of this research and the major questions it is attemptingto answer.
Second, we will describe a virtual-reality environment for mobile robotsimulation, designed and implemented to support this and other research. Wedescribe its design, implementation and performance.
Third, we will describe the “network{ XE "network" } of behaviours”concept. This concept, first described in [Tsotsos{ XE "Tsotsos" } 1997] isfleshed out for the first time, its important characteristics are described and the
2
integration between data-driven and temporal constrain type behaviourinterconnections is presented in detail, supported by experimental results.
Finally, in the context of S*{ XE "S*" }, we present a firstimplementation of a mission specification language that provides support fortask decomposition, synchronization and execution monitoring. This paperdetails and more formally defines the language originally presented in [Tsotsos{XE "Tsotsos" } 1997], moving beyond the pseudo-code used there. Examplesare presented.
The thesis will conclude with an overview of the original contributions,a brief description for a number of limitations identified in the language aspresented and the solutions proposed. We also present a series of ideas thatcould be used as directions of future research
1.1 Background
The sensing, thinking and acting parts of a robot's function must beorganized within some framework and must accommodate requirements on therobot's performance such as multiple sensors, uncertain processes, conflictinggoals, and planning. Two basic control paradigms have appeared for organizingthe control systems of an intelligent mobile robot: functional{ XE "functional" }decomposition (or centralized) and behaviour-based decomposition (ordistributed).
Horizontal (or functional{ XE "functional" }) decomposition is theclassical top-down methodology used in the design of many existingautonomous robot systems. This approach breaks the robot control problem intoseparate components, each of which is processed in turn, with the output of one
3
module acting as the input to the next. The components of a classical horizontaldecomposition are described by [Hu 1996] as (see Figure 1):
- Perception - a module to gather information from the environment
- Model - a module to build an environmental model from the robot'sperception of its environment
- Plan - a module to construct a plan for the robot
- Execute - a module that moves the robot based on the plan
- Motion controller - a module to provide low-level control of the robot
Perception
Model
Plan
Execute
Motor Control
Sensing
Action
Environment
Figure 1. Decomposition of robot operationalsoftware into horizontal structures
4
This architecture is also known as the sense-model-plan-act (SMPA)cycle. Some representative examples can be found in [Dudek 2000].
The main drawback of the functional{ XE "functional" } approach is itsinability to react rapidly to events or changes in the environment, since thecurrent cycle must first come to an end before the change can be observed, afterwhich the whole cycle must be traversed before any action can be taken. Thisproblem is compounded by the fact that the architecture imposes that eachmodule be complex enough to handle the most complex task that the robot isintended to perform, leading to long latency times. Imposing temporalconstraints, e.g. [Bekey 1996] is only a partial solution, and it comes with theprice of significantly increased software complexity.
The reactive control{ XE "reactive control" } paradigm is based ondecomposing the overall action by behaviour rather than by a deliberativeprocess, similar to views on animal models of intelligence, and especially thestudy of neuroscience, psychology and ethology. Some researchers attempt toimplement results from these disciplines as closely as possible, while otherschoose to abstract the underlying details [Arkin 1998, Dudek 2000]. Behaviourbased systems directly couple sensors and actuators (see Figure 2 for a simpleexample), and were introduced to deal with some of the difficulties encounteredin adapting classical planners to deal with low-level robot control.
5
Build Map
Explore
Wander
Avoid Obstacle
Sensing Action
Environment
Figure 2. Decomposition of robot operationalsoftware into vertical structures
The particular problems that reactive control systems are trying toaddress are, amongst others:
- Multiple goals - classical planners attempt to satisfy one single goal ata time, but robots must satisfy several goals simultaneously, such as safety,processing input, communicating, executing motions, etc. Each of these tasksmust be accomplished in real time, and the functional{ XE "functional" } modelof computation is not well suited to the task
- Multiple sensors - the real-time constraints of robot sensors imposerapid data retrieval, sensitive to both sensor data measurement rates and the rateof data transmission from the sensor to the software system
6
- Robustness - the low-level system must be relatively insensitive toconflicting, confounding or missing data from one or more of the robotssensors, the system performance should degrade gracefully with the failure ofsome hardware or software components
- Extensibility - the controls system should be easily modified to dealwith changes in sensor, task or locomotive configurations, also the addition ofnew behaviours should not disrupt existing functionality
The best known and most influential of the reactive architectures is thesubsumption control paradigm [Brooks 1986], consisting of a number ofbehaviour modules arranged in a hierarchy, different layers taking care ofdifferent behaviours. Lower level layers control the most basic behaviours ofthe robot, while higher-level modules control the more advanced functions, thusintroducing the concept of levels of competence [Brooks 1986]. The levels ofcompetence are:
- Avoid collisions
- Wander around in the environment
- Explore the world
- Build a map of the environment
- Sense changes in the environment
- Reason about the world
- Formulate and execute plans
- Reason about the behaviour of objects and modify plans accordingly
7
Each level of competence includes – “subsumes” – all lower levels. Theoverall behaviour emerges from the interaction of the various modules, whichmakes it hard to judge a priori, and it is very difficult to prove performance ortimelines.
For other examples of reactive control{ XE "reactive control" }architectures see [Arkin 1998] and [Dudek 2000].
A strong theoretical argument against the strict version of subsumptionis made by [Tsotsos{ XE "Tsotsos" } 1992, Tsotsos 1995], showing that it isonly appropriate for a very limited domain and that if scaling to human-likeperformance is desired, a number of enhancements must be permitted, in theform of intermediate representations, hierarchical organization, explicitrepresentations of goals and attentive processes. The argument starts from theneed to visually recognize targets as behaviour triggers, and is based on proofsabout the computational characteristics of visual search and a comparison ofunbounded passive vs. unbounded active search. If targets are not explicitlyknown and used to help guide the search, the search problem is NP hard, butknowledge of the target is explicitly forbidden in the strict behaviouristparadigm.
The first system to take advantage of these theoretical results ispresented in [Dickinson 1993], a paper that describes a robot vision system thatachieves complex object recognition. The system uses two layers of behaviours,performing planning and object recognition, respectively. In many respects thissystem can be considered a precursor of S*, the authors describing ahierarchical behaviour-based architecture with internal representations andbehaviours that are triggered by, read from and write to these internalrepresentations. While this paper is an important contribution to the domain ofadvanced behaviour-based architectures, it lacks the formal setting of S*, theideas are applied to a single domain, and we are not aware of any follow-upwork that would discuss these issues.
8
An important component of any robotic architecture is the languageused to define missions. Yoav Shoham’s work [Shoham 1993, Shoham 1994],and especially his proposal for agent-oriented programming as a ‘newprogramming paradigm, based on a societal view of computation,’ [Shoham1994] has been very influential in this area. His paradigm’s key idea, based onthe observation that humans use the intentional stance as an abstractionmechanism for representing the world, is that of directly programming robots interms of mentalistic, intentional notions that agent theorists have developed torepresent the properties of agents. In his view, an agent-oriented programmingsystem should have three components: a logical system for defining the mentalstate of agents, an interpreted programming language for programming agents,and an ‘agentification’ process for compiling agent programs into low-levelexecutable systems. In his first implementation, the Agent0 language uses thenotions of beliefs, commitments and capabilities. An agent is specified as a setof logical rules for entering into commitments and executing capabilities, interms of sets of beliefs. The language also supports simple communicativeactions for exchanging between agents. The AgentK extension [Davies 1994]increases the communicative capabilities. [Thomas 1993] presented a moreelaborate implementation in the form of her Planning Communicating Agents(PLACA) language, which addressed an important drawback of the previoussystems, the inability of the agents to plan and communicate via high-levelgoals, but, as in Shoham’s work, the relationship between the logic and theprogramming language is loosely defined. In neither case can the programminglanguage be said to truly execute the associated logic.
The METATEM and Concurrent METATEM systems [Barringer 1989,Fisher 1993, Fisher 1994], based on temporal logic, make stronger claims inthis respect. Execution of the agent program corresponds to iteratively buildinga logical model for the temporal agent specification. It is possible to prove thatthe procedure used to execute an agent specification is correct, in that if it ispossible to satisfy the specification, the agent will do so [Barringer 1989]
9
The fact that the programs are expressed in terms of if-then rules is amajor limitation of these and other agent programming languages (e.g. Rao’sAgentSpeak(L) [Rao 1996], Hindriks’ 3APL [Hindrik 1998], etc). As in expertsystems, goals may be achieved, but it is not easy to analyze and reason aboutthe behaviour of the agent and provide timing guarantees. Also, while someauthors talk about planning, in reality most of them are limited to dynamicallyselecting predefined plans from a library.
A number of languages are based on situation calculus [McCarthy1969], a formal calculus of situations that has become one of the favouriteapproaches to the problem of reasoning about time, action, and plans. Golog[Levesque 1997] uses the situation calculus to define complex actions forgeneral systems and has been used extensively in the control of mobile robots(e.g. an RWI 21 and a Nomad 200 used for delivery tasks [Tam 1997]. Gologprograms are defined in an imperative programming language using commonlanguage control structures. Actions in a given domain can be specified byproviding precondition and effects axioms. Precondition axioms state theconditions under which an action can be performed, while effects axiomsspecify how the action affects the world’s state. A number of extensions ofGolog have been presented, including ConGolog [De Giacomo 1997, DeGiacomo 2000], an extension that supports concurrency, providing facilities forconcurrent program execution, priorities, interrupts and exogenous actionsduring the program execution. Golog and ConGolog have a number oflimitations, mainly arising from the offline nature of planning. IndiGolog [DeGiacomo 1999] has all of ConGolog’s features, but also additional facilities foron-line planning, sensing and incremental execution that seem to make itappropriate for developing robust high-level control programs that involveplanning and reactive capabilities.
Few labs work in similar directions to that in the S* proposal, one beingthe UBC Lab of Mackworth. There, he and colleagues have developed a controlframework they term Constraint Nets [Zhang 1995]. This framework is a
10
formal model for building hybrid intelligent systems as situated agents. Arobotic system is modeled formally as a symmetrical coupling of a robot withits environment. The model has a formal semantics and in applying it to a robotoperating in a given environment, one separately models the dynamics of therobot plant, the robot control program, and the environment. The total systemmay then be shown to have various properties, such as safety and liveness,based on provable properties of its subsystems. The assumption that the robotand its environment form a closed system, and that each may be formallymodelled make this strategy a useful one in domains where most if not allvariables are controlled. [Albus 1996] is another researcher who is following arelated path proposing his RCS Reference Model Architecture. He also seeks toinclude goal-directed processes, hierarchical decomposition of goals andattentive processes in a flexible control structure; however, the proof-theoreticverification methods are missing.
1.2 S*{ XE "S*" } Framework
The S*{ XE "S*" } architecture, proposed and described in [Tsotsos{XE "Tsotsos" } 1997, Tsotsos 1995b, Tsotsos 1996] seeks to reconcile thesuccessful behaviour-based robot architectures with the results presented by[Tsotsos 1995] which show that mechanisms which were anathema in the earlybehaviourist dogma, such as attention and goal-directed processing are perhapsnecessary if vision is to be used as a major sensor. S* is a conceptual strategyfor control which facilitates these mechanisms. A language for mission planspecification is defined permitting the integration of deliberative and reactivespecifications and a proof procedure is sketched which can determine if aparticular behaviour set violates the timing and feasibility constraints of a
11
specific mission. Further, a unique method for determining whether a particularS* behaviour collection can satisfy a given mission is described.
The research presented here seeks to complete the specification of theproposed language for mission plan specification and to realize animplementation of the overall mechanism, to demonstrate the process ofconverting a mission description into a behaviour network{ XE "network" },and executing the mission on a simulated mobile robot.
In subsumption-style behaviour definitions, a behaviour acts directly onthe physical world. In S*{ XE "S*" }, this notion is generalized: the 'world' onwhich a behaviour may act may be an internal (logical) representation or anexternal (physical) representation. The world is added to the well-used sense-model-plan-act cycle to create a sense-model-plan-act-world{ XE "sense-model-plan-act-world" } (SMPA-W) cycle. A behaviour is taken to mean anyprocess which uses input available in one or more representations and causes aneffect to one or more (may be the same) representations. The representationsare defined as part of the agent. Each behaviour is represented as such anSMPA-W cycle. Behaviours may thus act on the external world, bymanipulating physical objects or causing the robot to move, or may act on theinternal world of the robot. That is, a behaviour may manipulate internalrepresentations, taking input from an internal representation and makingchanges to or creating another internal representation for use by subsequentprocesses. Intermediate representations, hierarchical organizations, attentiveselection, and explicit goals are thus all facilitated. Any subsumptionarchitecture can be realized using the S* architecture, but not vice versa.Although the SMPA concept is part of this definition, it should be noted that itis used as a means to decompose individual behaviours into component parts. Itis not used to partition the robot functions into a centralized strategy.
The usual approach to achieving real-time performance in robotics hasbeen to avoid or to minimize the role of vision through the use of other sensorsor through trivialized visual analysis in order to realize real-time operation. It is
12
claimed [Tsotsos 1995{ XE "Tsotsos" }] that attentive, goal-driven vision alsohas the capacity to realize real-time performance. In trivializing visual analysis,previous researchers have either used very low resolution sensors (e.g. theKhepera vision module consisting of a 64 pixel linear sensor [K-Team]) or haveimplemented a primitive form of attentional selection in vision; that is,selectively analyze parts of the visual world, and only analyze to the degreerequired in order to achieve some goal, all done in an ad hoc fashion, butnevertheless resulting is real-time performance. S*{ XE "S*" } attempts toinclude attentional selection and goal-driven processing in a more principledmanner and with broader scope.
Each behaviour, whether internal or external, is represented as anSMPA-W cycle (see Figure 3). Although the concept of SMPA control hasbeen criticized in the past, the criticism is due to its use as a single integratedcontrol paradigm. In S*{ XE "S*" }, it is used as a means to decompose thestages of computation within individual behaviours.
13
Sense
Model
PlanAct
World
Figure 3. The SMPA-W cycle
The elements of the cycle are defined as:
- World: contains two representations, an event window and an actionwindow. The event window makes accessible a relevant portion ofsome representation within the system. Similarly, the action windowopens up onto some set of representations. The world node alsocontains a set of demons that monitor the contents of the event window.These demons detect changes to the event representations of relevanttypes that act as triggers for the activation of the behaviour. In this way,the representations are not limited to be those of the external world onlyand more sophisticated forms of intelligent reasoning are permitted.Intermediate representations that can be manipulated permit internal
14
behaviours, yet are handled in the same manner as representations forexternal behaviours.
- Sense: a process that attempts to extract from the event window thestimuli of interest and perform a first level of processing,.
- Model: using a representation of a domain and the sensedrepresentation, a model is associated with subsets of the sensedrepresentation.
- Plan: a process that associates actions with models and determines theappropriateness of the association.
- Act: a process that invokes some manipulation of a representation thatrealizes a behaviour, acting on the action window of the world node.
Since behaviours can execute autonomously and in parallel, theyimpose a number of limitations on representations, especially regarding theintegrity of representation and conflict resolution. The latter issue will bediscussed in subchapter 3.2. To address the former, each representation has ascheduler that ensures that only one behaviour can write at one time, while allbehaviours may read at any time, but not between updates. This isaccomplished through the use of semaphores.
More detail can be found in the S*{ XE "S*" } papers and technicalreports [Tsotsos{ XE "Tsotsos" } 1997, Tsotsos 1995b, Tsotsos 1996],including exception handling, a behaviour augmentation scheme, and otheraspects, many of them being novel ideas in the robotics literature, and a firstimplementation is presented in [Rotenstein 2002].
[Tsotsos 1997]{ XE "S*" } introduces a language for mission planspecification that permits the integration of deliberative and reactivespecifications and a proof procedure is sketched which can determine whether a
15
particular behaviour set violates the timing and feasibility constraints of aspecific mission. The capacity to specify a mission after robot deployment canprovide the flexibility required for an autonomous robot to re-structure itsinternal behaviours in response to new conditions. Further, robotic controlmethods in general lack procedures that might allow a formal way of predictingperformance.
16
Chapter 2 Mobile Robot Simulator
2.1 System Background
While nothing can replace experimentation on a physical robot inaddressing the complicated issues of limited resources, sensory imperfections,time lags, mechanical characteristics and limitations, etc., virtual realitysimulators can be very useful in rapid prototyping of behaviours and missions,and in developing and testing new architectures. Also, in the context of highinvestment, high risk, space missions, the ability to simulate and visualizepossible execution outcomes of a plan under development under differentcircumstances is critical to the success of the mission. Thus, an important goalof any robotic architecture to be used in science-directed planetary missions isto provide scientists the ability to specify and observe the rover’s operation in avirtual environment so that the mission can be tested and refined in the safetyand comfort of a research lab before the final plan is communicated to the roverfor autonomous execution.
17
A system that would satisfy the needs described above has to comprisethree components: simulation, visualization and plan execution.
The robot simulator has to provide solutions to common mobilerobotics problems and be simple to use by non-experts, while flexible forexperts to extend and modify. It should simulate the kinematics of the rover’slocomotion, manipulator and mobile sensor systems and also provide allsensory inputs, with correct ranges, statistical distribution of responses, and soon.
The visualization module needs to be able to generate replicas of theterrain where the robot is located based on in-situ observations and simulatecamera views based on the mechanical and optical characteristics of thesystems on the rover. In order to be able to do this, the visualization moduleneeds to be able to represent a variety of terrain features, do texture mappingfrom real images and simulate varying lighting conditions.
The plan execution component is not specific to the virtual realityenvironment; it is the rover executive, and ideally it should not need to beaware whether it is running on a rover or in simulation.
2.2 Implementation
An initial step in this research was the development of a virtual-realityrobot and environment simulator, designed as a common platform for mobilerobotics-related vision research, providing generic software components thatencapsulate robotics functionality, low-level vision algorithms and a complexvirtual reality environment. The capabilities of the simulator make it a flexibleplatform for research, development and integration of new capabilities atdifferent levels of abstraction, while also providing generic solutions forcommon robotics problems, from the implementation of various (holonomic
18
and non-holonomic) locomotion systems to stereo vision. The components ofthe system can be easily extended or modified in order to accommodate variousrequirements. While this is an important first step, the implementation of thefirst two components was not the focus of this research, so not all the desiredfeatures have been implemented, the process was driven mainly by the currentneeds of the plan execution model and its evolving capabilities.
While the current implementation is restricted to the 3D representationof obstacles in an essentially flat (2D) world, the design of the system allowsfor the easy extension to 2 1/2D worlds and even to the simulation of 3Denvironments and movement for research in underwater, flight or orbitalrobotics. Thanks to the layers of abstraction that the simulated robot provides, itcan be used for research at any level ranging from low-level actuator control tohigh-level vision, from single robot systems to complex multi-robotcoordination.
To date, the usual approach to achieving real-time performance inrobotics has been to avoid or minimize the role of vision. Other sensors havebeen used or visual analysis is trivialized in order to realize real-time operation.The simulator presented here is intended to stand as the basis of research in theuse of visual attention and goal-driven processing for mobile robotics.
The simulator is designed to provide solutions to common mobilerobotics problems and is designed to be simple to use by non-experts, whileflexible for experts to extend and modify. The locomotion package simulatesthe kinematics of a variety of common drive types, including the populardifferential drive and non-holonomic car-like drive. The vision packagesprovide 2- and 3-D image processing as well as map building and handling.Each package provides default functionality, allowing for a quick starting pointfor people who need to use components outside their area of expertise. Thevision system is driven by the real-time simulated OpenGL camera views. Asseen in Figure 4, the camera system is very flexible, allowing for active visiontasks (the simplest example being the building of panoramic images of the
19
surrounding terrain), and is backed by a collection of image-processingalgorithms.
Figure 4. Image processing steps: top: BW cameraimages, middle: Laplacian images, bottom:disparity map used by navigation module
One very important capability of the virtual reality system is the abilityto simulate multi-agent systems. This capability is implemented in a veryflexible manner, such that each robot can have different physical characteristics(size, locomotion system, sensor array) and control strategy. This permits thetesting of cooperative or competitive behaviours. Examples of potential usesinclude distributed map building (cooperative behaviour) and an evasion-pursuit game (competitive behaviour). This capability has been built into thesystem having in mind future research, but it was not used in this research.
20
The virtual reality environment is based on OpenGL, due to itsportability and wide availability of hardware support. The display consists of aconfigurable number of windows that represent views of the various sensors onthe robot. The main window represents the view from the rover’s main camerasystem, which can be a mast-mounted stereo system, with left and right cameraviews, or a single camera (see Figure 5).
Other optional windows represent the proximity sensor readingssimulating an array of sonar detectors commonly available on commercial andresearch mobile robots, the collision sensors and depth information extractedfrom the stereo views.
The display is updated in real time based on the mechanicalcharacteristics of the robot, such as the maximum speed and acceleration of thelocomotion system and position, displacement, roll, pitch and yaw of thecamera system by simulating the kinematics of the robot and its subsystems,and their interaction with the environment. The level of detail in thesesimulations is sufficient for the purposes of this research, details such as thedynamics of the locomotor-soil interaction being simplified, but in case there isinterest in research in these directions, the structure is simple and flexible, beingdesigned with extensibility in mind.
21
Figure 5. Simulator screenshot: 1a, 1b - viewsfrom left and right cameras, 2 - collision sensor, 3- proximity sensor, 4 - bird's eye view, with whitelines indicating the field of view of the cameras
The simulator is built in a modular fashion, taking advantage of theexpressive power of the object-oriented software development methodology.Generic classes are provided for the very high level concepts involved, such asterrain_feature for the various objects that make up the landscape, locomotorfor the various kinds of robot modules that can be described using kinematicsand sensor for the various means that robots use to sample the environment.These classes represent an abstract view of the physical reality, and providegeneric public interfaces for the derived physical classes.
For the graphical display, classes derived from terrain_feature provideimplementation for physical entities such as the ground, the sky, rocks and soon. In order to allow for rapid development and testing of vision algorithms,non-realistic terrain features are also implemented, such as textured cubes andcoloured spheres. Users can also add their own types of terrain features in orderto enhance the realism of the simulation (e.g. sand dunes, craters, etc).
22
Implementers of such terrain features have to define in addition to geometricand graphic specifications, characteristics of the interaction between the robotsand these new terrain features, e.g. visibility by proximity sensors, collisioncharacteristics, impact on robot motion, traversability, etc.
A simulated robot is a collection of sensors and locomotors (see Figure20 in Appendix B for the classes involved). In our case the sensor arraycontains collision and proximity sensors and a stereo camera mounted on amast. The simulated robot also contains two locomotion systems, a differentialdrive mobility system and the mast for the stereo camera system, with 4 degreesof freedom (height, roll, pitch and yaw). The locomotors simulate thekinematics of a real locomotion system, implementing limits on acceleration,speed and angles of rotation. Due to the fact that mechanical systems are ingeneral many orders of magnitude slower than microprocessors, locomotorsprovide time estimates for motions in two formats: the control system can querywith a desired motion and the locomotor will provide a time estimate forexecuting the command, or the control system can query for the time left toexecute the current command. Locomotors can accept and process commandsin two modes, blocking (i.e. no commands can be issued until the currentcommand has been completed, with the possibility of emergency overrides) ornon-blocking (i.e. commands are executed as issued, commands that are in theprocess of execution are abandoned and it is the controller’s responsibility toensure the consistency of the system). In order to allow controllers of varyingdegrees of abstraction to be built, locomotors accept commands at any level,from high-level commands such as “move forward (distance)” or “turn left(angle)” to low-level commands such as “set left motor speed (value).”
While the robot simulator and virtual reality environment have not beenthe main focus of our research, we consider it to be a significant contributiontowards the goal of building vision-based mobile robots for planetaryexploration. The complexity and level of detail are not at the same level assome of the similar systems available, but the flexible design and the unique
23
focus on vision as the main sensor make this a very powerful tool for research,and if future developments will make it necessary, the framework is in place tosupport easy enhancement of the virtual reality environment in the any of anumber of directions, such as the addition of other kinds of locomotionsystems, more precise simulation of the kinematics involved, 2 1/2D and 3Dmotions and the addition of new sensors and manipulators.
24
Chapter 3. Mission Specification Language
Intelligent agents must be capable of executing a variety of missions, and thusface a much more difficult task than single-mission systems. Generally,STRIPS-like planners provide sequences of steps that must be executed, takinginto account motion and sensor uncertainty by including localization andcorrection steps explicitly in the plan. Attempts to capture and integratereactivity in this kind of plan (or, conversely, to structure behaviour-basedsystems in a way that is compatible with planning) have had varying degrees ofsuccess. Modern mission specification languages, as those presented inChapter 1, facilitate the development of robotic systems that are:
- Able to do reasoning and planning
- Able to react to the environment
- Able to monitor mission execution
- Integrate reactive and deliberative behaviours
25
- Programmed in high-level languages
In general the systems developed have two characteristics: there is a clearseparation between the deliberative and reactive parts of the system, and specialmodules do the monitoring. The former is in general a reasonable approach, butit introduces a split in the definition and capabilities of the system, which has asa consequence the fact that usually the reactive part of the system can not becontrolled by mission programs, and the systems generally have highcomplexity, leading to engineering problems, especially when it comes toextending the capabilities of the system with new modules. The lattercharacteristic means that monitoring is implemented outside the normal flow ofthe mission and not under mission developer control. Since it is very likely thatdifferent stages of complex missions operate under different constraints, andthus require different monitoring, this aspect should be under user control in aflexible and uniform manner. The language proposed in [Tsotsos 1997]addresses these two issues in the context of the S* framework, while at thesame time providing the normal temporal constraints that characterizeprogramming languages used in robotics control. After presenting the languagein this chapter, we will present the aspects of S* that are needed to support thelanguage at runtime in Chapter 4, followed by a description of theimplementation and examples of usage in Chapter 5. This exercise will identifya number of shortcomings of the language and potential solutions will bepresented.
3.1 The Language
26
3.1.1 Sequences Of Behaviours
We will introduce the mission specification language gradually, througha series of examples that justify all its components. In its simplest form, amission is a series of steps that have to be executed in sequence:
start
Step 1;Step 2;Step 3;Step 4;
end
These steps could be defined at any level of abstraction, but the simplestand most obvious thing to do is to use actual behaviour names in the language.This has a number of advantages, ranging from the readability of the programto the ease of implementation. Also, this will make life easier for any futureattempts to validate missions and extract their properties, work that is beyondthe scope of this research.
The grammar that specifies well-formed missions is:
mission <- start behaviour_list endbehaviour_list <- behaviour ; | behaviour_list; behaviour;
3.1.2 Temporal Connectors
27
This simple temporal sequence is obviously sufficient only for thesimplest of missions, so temporal grouping constructs are needed to enhancethe expressive power of the language, especially since S* permits allbehaviours to be active in parallel. We need to be able to express parallelismand to connect events in time. The default behaviour connector is the semicolonand it implies that two steps (behaviours) are to be executed one after the other.
The binary connectors used, illustrated graphically in Figure 6, are:
- starts with: the two behaviours start together
- within: the first behaviour starts after and ends before the second one
- during: the first behaviour starts during the execution of the second one
- starts after <time>: the first behaviour starts after the end of the secondone (after an optional time delay)
- ends with: the two behaviours end at the same time
- ends during: the first behaviour ends during the execution of thesecond one
Also, an arbitrary number of behaviours aligned by start time or endtime are represented as [b1, b2, …) and (b1, b2, …] respectively. Here is anexample mission that uses a few of these constructs:
start
find landmarks A, B starts with localize;go to landmark A within track landmark B;
end
28
A
BA starts with B
A
BA within B
BA starts during B
A
B A starts after B(optional time delay)
A
BA ends with B
A
BA ends during B
A
Figure 6. The temporal connectors betweenbehaviours
The resulting grammar is:
mission <- start behaviours endbehaviours <- behaviour | behaviour_list | behaviours connector behaviours
29
behaviour_list <- [b_list) | (b_list]b_list <- behaviour | b_list, behaviourconnector <- ; | starts with | within | during | starts after time | ends with | ends duringtime <- null | number
3.1.3 Grouping Constructs - Phase
A grouping construct is introduced, called a phase, used to labelsequences of actions for reuse, similar to a function or procedure call in atraditional programming language.
Here is a simple usage example, a planetary rover that takes apanoramic view of its environment, localizes and approaches a target whiletracking it, marks its position and takes another panoramic view (note the use ofnested phases in ANALYZE_TARGET):
startphase MAKE_PANORAMA { raise mast; take snapshot; turn camera 45 degrees left; take snapshot; turn camera 45 degrees left; take snapshot; turn camera 45 degrees left; take snapshot;
30
turn camera 45 degrees left; lower mast;}phase WHERE_AM_I { raise mast; find landmarks A, B; localize; lower mast;}phase APPROACH_TARGET { go to landmark A within track landmark A;}
phase ANALYZE_TARGET { localize; MAKE_PANORAMA}
WHERE_AM_IMAKE_PANORAMAAPPROACH_TARGETANALYZE_TARGET
end
The associated grammar:
mission <- start phase_def behaviours endphase_def <- null | phase phase_defphase <- phase phase_id {behaviours}behaviour_atom <- behaviour_id | phase_idbehaviours <- behaviour_atom | behaviour_list | behaviours connector behavioursbehaviour_list <- [b_list) | (b_list]
31
b_list <- behaviour_atom | b_list, behaviour_atomconnector <- ; | starts with | within | during | starts after time | ends with | ends duringtime <- null | number
It is apparent from this that the language does not differentiate betweena definitions stage and an execution stage. While this is not so much of aproblem here, it will soon become apparent that the language could benefitfrom such a separation.
3.1.4 Grouping Constructs – While-Ensure
As mentioned before, the aspect that sets the language proposed in[Tsotsos 1997] apart is that, aside from being able to specify robot actions intheir temporal relationships, it allows the programmer or planner to specifyaspects of the environment of which the robot must be vigilant during theexecution of various stages of the plan. We include a second groupingconstruct, called a ‘while-ensure{ XE "while-ensure" }’ primitive, so that for acollection of plan steps, actions may be associated with a clause to ensure that
32
particular conditions are met (e.g. “ensure that the position is within a certaintolerance,” “keep a safe distance from obstacles,” etc.). These groupingconstructs can be nested. The nesting permits for sub-phases of a mission toproceed with localized constraints, tightening or relaxing the ensure clauses.The while part of the while-ensure construct is identical to a phase, in that it isnothing more than a grouping construct. The ensure part can contain threetypes of information:
- Ensure behaviours: behaviours that need to execute for the duration ofthe while construct, i.e. in parallel with all the behaviours included inthe while
- Prohibited behaviours: behaviours that must not execute at the sametime as the while construct, identified by a preceding “!”, similar to the“not” logical operator used in traditional programming languages
- Boolean clause: a Boolean clause that needs to be periodically evaluatedfor the duration of the while construct, the frequency of evaluationbeing specified in an optional argument.
Examples of ensure behaviours would be obstacle avoidancebehaviours, tracking behaviours, or position validation behaviours. Similarly,prohibited behaviours could be, for example, yielding the right of way in asituation where continuous motion is critical. Boolean conditions can beexpressions that include comparisons between the values of variousrepresentations and other representations or mission specified values, such as,for example, the minimum distance to obstacles should not go below a certainvalue, the speed should not exceed a maximum value, the battery charge shouldnot decrease below a certain threshold.
The grammar becomes:
mission <- start phase_def while_def behaviours end
33
phase_def <- null | phase phase_defwhile_def <- null | while phase_def while_defphase <- phase phase_id {behaviours}while <- while while_id {behaviours}ensure (time predicate)behaviour_atom <- behaviour_id | phase_id | while_idbehaviours <- behaviour_atom | behaviour_list | behaviours connector behavioursbehaviour_list <- [b_list) | (b_list]b_list <- behaviour_atom | b_list, behaviour_atomconnector <- ; | starts with | within | during | starts after time | ends with | ends duringtime <- null | numberpredicate <- behaviour_preds | boolean_preds | behaviour_preds && boolean_predsbehaviour_preds <- behaviour_id | ! behaviour_idindividual_arg <- representation_id | number | symbolboolean_preds <- boolean_preds && boolean_preds | boolean_preds || boolean_preds | (boolean_preds) | individual_arg = individual_arg | individual_arg < individual_arg | individual_arg <= individual_arg | individual_arg > individual_arg | individual_arg >= individual_arg
34
We could modify the mission in the previous example to take advantageof the new construct:
start
phase MAKE_PANORAMA { raise mast; take snapshot; turn camera 45 degrees left; take snapshot; turn camera 45 degrees left; take snapshot; turn camera 45 degrees left; take snapshot; turn camera 45 degrees left; lower mast;}
phase WHERE_AM_I { raise mast; find landmarks A, B; localize; lower mast;}
phase APPROACH_TARGET { go to landmark A within track landmark A;}
phase ANALYZE_TARGET { localize; MAKE_PANORAMA}
while THE_MISSION { while W1{ WHERE_AM_I MAKE_PANORAMA } ensure (speed==0) APPROACH_TARGET
35
while W1{ ANALYZE_TARGET } ensure (speed==0)} ensure ()
end
In this case we identified sections of the mission during which it isimportant that the robot is stationary, and we will describe the mechanisms thathave been designed to perform this task. Also note that ensure clauses can benested, a solution will be presented on integrating the various levels.
The problem identified earlier, namely the absence of a clear separationbetween a declarative stage and an execution stage, is apparent here. Theimplementer is faced with the problem of multiple while-ensure constructs,and a decision has to be taken on how to interpret them, i.e. how to separatedefinitions from invocations. For phases, the decision we took is that all can beconsidered declarations. For while-ensure constructs, a number of possibilitiesexist. We decided to consider all but the last as definitions, the last one beingthe single execution stage of the mission. This is obviously not the best long-term solution, and we suggest the following change to the mission specificationlanguage: the mission description starts with a list of phase and while-ensuredefinitions, potentially labelled by an identifier keyword, and the executionstage is a list of behaviours, phase and while-ensure constructs, containedbetween the start and end keywords, and connected by the normal temporalconnectors (the default being sequential execution). This solution was notexplored in the present research, but we consider it an important observation,that warrants further investigation.
3.1.5 Behaviour Parameters
36
To make the language and the missions that it can define more flexible,it is important to provide the flexibility to allow behaviours to act on variousrepresentations, rather than having the link hard-coded in the design stage, as isthe case in most behaviour-based systems. The examples presented earlier, suchas:
turn camera 45 degrees left;and find landmarks A, B;
while making use of parameters, do it in a very ad-hoc manner and wouldrequire natural language understanding capabilities that, while technicallyfeasible, are beyond the scope of this research. A formal definition in the styleof most traditional programming languages is simple and flexible enough to bea good candidate, resulting in the following grammar, which adds parameters tobehaviours in the form of lists of representations, numbers and symbols:
mission <- start phase_def while_def behaviours endphase_def <- null | phase phase_defwhile_def <- null | while phase_def while_defphase <- phase phase_id {behaviours}while <- while while_id {behaviours}ensure (time predicate)behaviour_args <- null | individual_arg | behaviour_args , individual_argindividual_arg <- representation_id | number | symbolbehaviour_atom <- behaviour_id ( behaviour_args ) | phase_id | while_idbehaviours <- behaviour_atom | behaviour_list | behaviours connector behaviours
37
behaviour_list <- [b_list) | (b_list]b_list <- behaviour_atom | b_list, behaviour_atomconnector <- ; | starts with | within | during | starts after time | ends with | ends duringtime <- null | numberpredicate <- behaviour_preds | boolean_preds | behaviour_preds && boolean_predsbehaviour_preds <- behaviour_id (behaviour_args) | ! behaviour_id ()boolean_preds <- boolean_preds && boolean_preds | boolean_preds || boolean_preds | (boolean_preds) | individual_arg = individual_arg | individual_arg < individual_arg | individual_arg <= individual_arg | individual_arg > individual_arg | individual_arg >= individual_arg
Thus, the previous example becomes:
start
phase MAKE_PANORAMA { raise mast(); take snapshot() turn camera (45); take snapshot(); turn camera (45); take snapshot(); turn camera (45); take snapshot();
38
turn camera (45); lower mast();}
phase WHERE_AM_I { raise mast(); find landmark (A); find landmark (B); localize(); lower mast();}
phase APPROACH_TARGET { goto landmark (A) within track landmark (A);}
phase ANALYZE_TARGET { localize(); MAKE_PANORAMA}
while THE_MISSION { while W1{ WHERE_AM_I MAKE_PANORAMA } ensure (speed==0) APPROACH_TARGET while W1{ ANALYZE_TARGET } ensure (speed==0)} ensure ()
end
Further examples of usage are presented in [Tsotsos 1997], where thenecessity of the various constructs of the language is also justified. Note thatthe examples referenced above are presented in pseudo-code format. The
39
implemented syntax is presented in the next sub-chapter, in Appendix A andexamples are presented in Chapter 5.
3.2 Language As Implemented
The grammar presented above is slightly different from the onepresented in [ Tsotsos 1997] and its variants ([Tsotsos 1995b, Tsotsos 1996]).First of all, in the process of designing the lexical and semantic analyzers, a fewminor omissions became apparent. For example, definitions are presented forphases, but it is not specified in the grammar how these are to be used in amission, since the mission definition is simply:
mission <- start behaviours end
and thus no indication is given as to where phase definitions could occur in amission. Also a number of definitions are compressed to increase readability,and would result in contradictory or incomplete definitions (reduce-reduce andshift-reduce errors).
Among other unresolved issues in the original presentation of thelanguage is the issue of behaviour parameters, the definition being:
parameter <- {possible system parameters}
This less than rigorous definition had to be clarified, so we restricted thepossible parameters to the following three categories:
- Representations – since behaviours read and write information to andfrom representations, this is a natural choice, and for example the
40
sequence find landmark (A); find landmark (B) can beinterpreted as “the system contains two landmark representations,labelled A and B, the find landmark behaviour needs to firstexecute using the information contained in representation A, and then itshould execute using the information contained in representation B”
- Numbers – certain behaviours take numeric arguments, for exampleturn camera (45) will turn the camera mast the specifiednumber of degrees, while move forward (10) will cause the robotto move forward the specified distance.
- Symbolic arguments – a catch-all type of argument, for cases where theabove will not be appropriate, for example when a subset of a particularrepresentation needs to be addressed, or when the data required does notexplicitly exist in the system, but a function call is needed to generate it.For example, the case presented under representation arguments couldnot be used if the designer decides to have a single landmarkrepresentation, in the form of a list of landmark data structures. In thiscase A and B have to be symbols that need to be resolved at the time themission is processed.
The issues raised by the various types of parameters and theirimplications on the design of the system will be discussed thoroughly inChapter 5.
41
Chapter 4. Behaviour Networks1
4.1 Behaviour Interaction
Various methods have been proposed to handle interactions betweenconflicting or incompatible behaviours, such as output arbitration, behaviourcoordination mechanisms and mutually exclusive behaviour executionconditions [Arkin 1998]. [Tsotsos{ XE "Tsotsos" } 1997] in the original S*{XE "S*" } proposal offers a hybrid solution, with locking at the representationlevel ensuring multiple reads and single write, output arbitration for actuators,with specialized arbitration behaviours associated with actuator representations,behaviour incompatibilities resolved through representations (e.g. a collisionbehaviour is supposed to mark the fact that a path to the target is not available,and any target approach behaviours will take appropriate steps, such asstopping until the obstacle is avoided), and control flow through exceptions.
Here we will quickly review a few of the options available, with thedesire to evaluate the most appropriate solutions for S* and in particular for theimplementation of the mission specification language, followed by a discussionand justification of the chosen solution. For a more thorough review see[Rotenstein 2002], where further aspects of S* are taken into consideration,such as the detailed structure of behaviours and complex interactions such asbehaviour augmentation and exceptions are discussed, issues that, whileimportant for progress in the study of S*, have little bearing on the language 1 The results presented in this chapter represent work done in cooperation with Andrei Rotenstein (see
[Rotenstein 2002])
42
and its implementation, our purpose being mainly to interpret a mission andtranslate it into a meaningful network of behaviours. Of course, great care wastaken in making sure that the solution proposed did not interfere with theseaspects, and it is worth mentioning that our conclusions are very similar tothose presented in [Rotenstein 2002], so the analysis did not miss any importantaspect, and is compatible with the aspects of S* that we are not presenting here.Also, [Arkin 1998] and [Dudek 2000] contain detailed discussions of the topicin a more general setting.
4.1.1 Competitive Methods
When two or more behaviours are active at the same time, conflictsbetween their independent responses can result. Competitive methods provide ameans of coordinating behavioural responses for conflict resolution, and can beviewed as a winner-take-all network in which the output of a single behaviourprevails and directs the robot. Competitive strategies presented in the literaturecan be grouped in three broad categories.
Arbitration requires that a coordination function serving as an arbiterselect a single behavioural response [Arkin 1998]. The most common approachto arbitration takes the form of a fixed priority network based on strictbehavioural dominance, through suppression and inhibition (e.g. [Brooks 1986,Mataric 1993]).
Action selection methods ([Maes 1990]) allow behaviours to competethrough the use of activation levels driven by the agent’s goals and incomingsensory information; no fixed hierarchy is established. Lateral inhibition is onepossible implementation.
43
[Rosenblat 1989, Rosenblat 1995] propose a voting system, wherebehaviours do not generate actions, but vote on a predefined set of discretemotor responses. Arbitration takes place in a winner-take-all fashion, the singleaction with most votes being executed.
[Tsotsos 1997] proposes arbitration behaviours associated with each ofthe robot’s actuators, but does not specify their function. These can take anumber of forms, ranging from simple priority schemes to complex decisionalmechanisms, and we will discuss them after an overview of cooperativeschemes.
4.1.2 Cooperative Methods
Cooperative methods attempt to fuse the outputs from multiplebehaviours, providing the ability to use them concurrently. The key to thesemethods is finding representations that make it possible. Potential field methods([Khatib 1985], [ Krogh 1984], [Latombe 1991]) provide a useful formalism,with vector weighted summation or superposition being the favoured methods.Behaviour blending is discussed theoretically in [Saffiotti 1995]. This methodseems to have good results in tasks that involve physical motion such asmanipulation and navigation, i.e. where vectors are a natural representation forthe task. It is unclear how the method could be extended to other types of taskswith any confidence that correct and predictable results would be obtained.
4.1.3 Discussion
44
In the case of S*, a number of special circumstances have to be takeninto account in discussing behaviour integration, as they are not generallypresent in behaviour-based systems. Behaviours can be connected throughhard-coded networks, basically forming behaviour-based systems with internalrepresentations, or they can form mission-based dynamical networks withtemporal constraints. Behaviours can - and in some cases will certainly –execute in parallel. Representations store three kinds of data: sensory input,internal state (including processed sensory input) and actuator data. The widevariety of possible types of data stored in representations and the associatedrules of update makes it very unlikely that a “one size fits all” solution can befound.
Arbitration, while appropriate for simple behaviour-based systems, dueto their strict ordering of behaviours in a hierarchy, is unlikely to be sufficientfor a distributed and decentralized system such as S*. It is also argued that apredefined priority network is inappropriate, due to the fact that it is unable todistinguish ([Tsotsos 1995]):
- Priority due to an emergency
- Priority due to a logical sequence of events
- Priority due to execution of a causal chain of events in a plan
- Arbitrary priority used to break a deadlock
It is suggested by [Tsotsos 1995] that the problem could be solved usingmeta-rules associated with each of the nodes of the S* structure, thus avoidingthe problems raised by large, centralized meta-rule sets used in expert systems.
Action selection is an interesting method, and shows promise, but it isunclear how reactive and deliberative aspects of a mission can be integrated andno theoretical argument is made suggesting that its capabilities exceed those of
45
other behaviour-based systems. As such, the benefits of integrating this solutionwith S* are unclear, and significant preliminary theoretical work would have tobe completed before this could be attempted. At least intuitively, this could beaccomplished with relative ease in S* by defining appropriate activationbehaviours and making daemons sensitive to thresholds in input values or torate of change.
The spirit of voting systems is very much incompatible with S*, wherethe focus is in generating actions dynamically to take the robot towards a widevariety of goals in a wide variety of missions, rather than selecting from apredefined list of actions. Voting systems would most likely suffer from severescalability problems, and it is also unclear how such a system would deal withcomplex internal representations, where actions (i.e. data to be written) are theresult of a reasoning process or of complex algorithms, and can in no way beselected from a predefined list.
Cooperative schemes, as mentioned before, seem only appropriate fordirect motor output, and when used carefully seem to have an advantage overother schemes. For example, in an application that requires the traversal of(partially) unknown terrain, integration between traversal and obstacleavoidance would provide better results than competitive solutions. For safetyreasons, obstacle avoidance has to take precedence over motion towards atarget, but if the obstacle avoidance system is not aware of the overall goals, itcan have significant negative side effects. On the other hand, integrating theusage of goal type information into the obstacle avoidance behaviour isproblematic from an engineering point of view, reducing the reusability of thebehaviour, increasing significantly its complexity, which is undesirableespecially for a safety-critical behaviour. The solution offered by cooperativeintegration allows the system to both follow the goal and avoid the obstacle,thus minimizing the impact of behaviour side effects.
It is fairly obvious from this discussion that none of the traditionalschemes is entirely appropriate for the needs of S*. As mentioned earlier,
46
[Tsotsos{ XE "Tsotsos" } 1997] in the original S*{ XE "S*" } proposal offers ahybrid solution, with locking at the representation level, output arbitration foractuators, resolving behaviour incompatibilities through representations, andcontrol flow through exceptions.
Thus, a first and mandatory line of defence in the system has to protectrepresentations from inconsistencies due to simultaneous writes and fromreading during updates, while at the same time allowing multiple reads to occurin parallel. This can be easily accomplished with a traditional resource sharingmechanism through the use of semaphores and since techniques and their useand consequences have been extensively studied, we will not discuss this anyfurther.
Specialized arbitration behaviours associated with actuatorrepresentations (and with any representation for that matter, there is nothingspecial about the way actuators are represented) can be done at several levels,ranging from plain priority schemes to complex decisional heuristics. Forsimple priority schemes this route is only one of the possible implementations,and in our opinion simpler approaches can lead to the same results. Creatingarbitration behaviours that implement a simple priority scheme is not advisablefor a number of reasons:
- For every representation that needs arbitration, we introduce an extrabehaviour and a number of representations equal to the number ofbehaviours that need to be arbitrated, to store the intermediate results,adding to the complexity of the system and reducing its reactiveness
- The decision to use a particular behaviour is delayed, so behaviours areallowed to execute, even though results may be discarded, increasingthe system load pointlessly.
- Since a behaviour can write to multiple representations, each potentiallywith its own priority scheme, we need an extra mechanism to ensure
47
that decisions are consistent, and while this is trivial if the conflicts arebetween the same sets of behaviours for each representation, it becomesa very complex problem if decisions have to be taken on disjoint sets ofbehaviours.
- The arbitration behaviour needs to be updated and new intermediaterepresentations created each time new relevant behaviours are added tothe system, reducing one of the benefits of behaviour-based schemes,namely that new behaviours can be added to the system withoutmodifications to other behaviours.
At the other extreme, complex arbitration behaviours, in addition toinheriting the ones mentioned above, suffer from significantly more difficultproblems, caused mainly by the fact that the arbitration behaviour has to beaware of the reasons why the behaviours have been activated and the reasonswhy they attempt to update representations the way they do, it has to be awareof the overall state of the system, of relative priorities between the conflictingbehaviours and of goals and priorities, to name just a few. This makes thesolution impractical, because it is easy to see the arbitration behaviour growingin complexity to the point where it becomes more complex than the behavioursit is attempting to arbitrate, and it can be argued that since it is so smart, wemight as well discard the arbitrated behaviours, and let this complex piece ofcode do the whole work.
The third idea presented by [Tsotsos 1997] is to resolve behaviourincompatibilities through representations. For example, when the collisionbehaviour is triggered through the collision sensor representation, it is supposedto mark the fact that the path is obstructed, and the path following behaviourwill know that it needs to stop until the path is cleared or a new path is found.While this idea has significant merit, its general applicability is questionable,both on a conceptual level and on a practical, engineering level. Conflicts thatarise between high-level behaviours, such as target approach, and low-levelbehaviours, such as obstacle avoidance, need to be resolved (in general) in
48
favour of the low-level behaviours that ensure the safety and integrity of therobot and its environment. The proposal has three implications:
- The low-level behaviour, necessarily a fast, real-time process, isburdened by having to write to representations that trigger theconflicting high-level behaviours, signalling that, for example, the pathis blocked.
- The low-level behaviour needs to be aware of the overall state of thesystem and the current goals in order to know what information it needsto write, and into which representations.
- Since this scheme hard codes the relationships in the behavious, it isunclear how flexibility could be built in, and how it could be adapted tovarying needs in various stages of a mission in a consistent and rigorousfashion.
The first two issues involve high-level decisions and messages, outsidethe area of expertise of a low-level, safety-critical behaviour. While thisargument is not intended to discard the idea completely, it is obvious that itsapplicability is limited to the interaction between behaviours at the same levelof complexity and with similar types of expertise.
Also it is unclear how any of these proposals can address the list ofprohibited behaviours present in ensure clauses in a consistent manner. Indeed,any of these solutions can deal with the problem, but behaviour-specificknowledge would have to be present in the network building process, makingthe whole process inconsistent, error-prone, and very hard to maintain.
[Tsotsos 1995, personal communications] indicates that the preferredmethod of handling conflicting situations is through the use of exceptions. Wehave chosen not to implement this method because a number of theoretical andpractical questions beyond the scope of this research need to be answered
49
before work can proceed in this direction. First of all, a behaviour needs to beable to detect its own failures in order to generate the exception, and it isunclear what the theoretical limits are on doing this with the incomplete andincorrect data provided by real sensors. Also, exception handling tends to be acomplex and heavy-handed approach to control flow, so a thorough analysis ofperformance issues has to be undertaken. Initial answers to these and otherquestions, as well as a first implementation of an exception handlingmechanism in S* are presented in [Rotenstein 2002], but they were notavailable at the time this research was undertaken. Once final results areavailable, the language and the exception handling mechanism need to beintegrated, and this is one of the most important items identified for futureresearch.
4.1.4 Proposed Solution
Apart from the representation integrity scheme, deemed mandatory, thedifficulties associated with the methods presented above have led us to asolution that is much simpler conceptually, does not add significant overhead tothe system, is flexible and decentralized, can be updated dynamically at runtimeand is more in the spirit of distributed behaviour-based systems such as S*.
We propose a distributed priority scheme with mutual inhibitionbetween behaviours. This is accomplished by attaching to each behaviour a listof incompatible behaviours, and whenever the daemon decides that a behaviourshould execute, inhibition requests are sent. What behaviours are deemedincompatible is a decision that has to rest with the designer of the specificapplication, since what constitutes an undesirable interaction betweenbehaviours in one context, could be desirable in another.
50
This proposal addresses the previously identified problems, having thefollowing characteristics:
- Information is distributed; the system associates a list ofincompatibilities with each behaviour. This avoids the scalabilityproblems caused by searching a large space of priority rules, and therules can be implemented at whatever level of abstraction is desired.
- The decision is a priori. This means that the system is not burdened withexecuting behaviours whose results will be discarded and the possibilitythat different decisions will be taken by different representations,resulting in inconsistencies, is avoided.
- The information can be dynamically updated. This means that thescheme is flexible and can be adapted to the needs of particular stagesof the mission.
- The network building can proceed without any knowledge about thestructure of the behaviours and representations involved.
- Requests for inhibition and reactivation, being treated locally, can easilybe paired.
- The scheme is compatible with almost any other approach. Thus, thedesigner of a system is free to use whatever approach is deemed to bethe most appropriate to solve particular problems that arise, withoutbeing restricted by our decision.
The problems identified previously are thus addressed, and while wecan not claim that this solution is the best and most efficient in any situation,the inherent flexibility of the scheme ensures that it is powerful enough toaddress most issues and discreet enough not to stand in the way when othersolutions are more appropriate. We will show an example where we
51
successfully integrate this scheme with behaviour cooperation, takingadvantage of the strength of both methods.
It could be argued that this is to a certain extent only a poorimplementation of exception handling. We claim that this is not the case, for atleast two reasons. With exception handling, special consideration has to begiven to the list of prohibited behaviours specified in the ensure clause, whilethis solution integrates them naturally, as we will see in the next subchapters.Also, this scheme does not rely on behaviours being able to detect their ownfailures. After all, not all incompatibilities between behaviours would result infailures for one of the behaviours, and what is an incompatibility in oneapplication can be a desirable interaction in another.
While this discussion is somewhat limited by the scope of this research,and a number of cases that are relevant to S*, such as behaviour augmentationand exception handling, have not been taken into account, we are confident thatthe proposed scheme will not interfere with, and may even facilitate theirimplementation. This analysis is taken further in [Rotenstein 2002], a paper thatreports on the ongoing research into the capabilities of S*, research thatinvestigates issues such as performance, stability, reaction to exceptional states,deadlocks, etc.
4.2 Extended Behaviours
The concepts presented until now, including behaviours triggered bychanges in representations, representations being read by and written to bybehaviours, and the temporal connections between behaviours form a network{XE "network" } of behaviours that defines the overall functionality of the robot.In order to allow for the flexibility required by both the static, hard-codednetwork scenario and the mission specification language, we need to define the
52
elements that form the connections and the structures that support the behaviourat runtime.
In S*{ XE "S*" } the definition of the world presented in the SMPAarchitecture has been extended to include both the external (physical) world andthe set of internal representations. This extended definition of the world isadded to the SMPA cycle to create a sense-model-plan-act-world{ XE "sense-model-plan-act-world" } cycle (see Figure 3), and each behaviour isrepresented as one such cycle. Thus, behaviours can read information from andact on the physical world, through manipulators or through robot motion, orfrom/on the internal world of representations. Intermediate representations,hierarchical organization, attentive selection and explicit goals are all facilitatedand in fact enforced, as argued in [Tsotsos{ XE "Tsotsos" } 1995].
In the rest of this thesis, we will use the term “pure behaviour” todescribe the SMPA part of these SMPAW cycles (i.e. the actual code thatimplements the functionality of the behaviour), and “behaviour” or “extendedbehaviour” for the composite object comprising of the pure behaviour andadditional data structures needed for its execution and its integration innetworks of behaviours.
These extended behaviours are composed of (see Figure 7 and Figure21 in Appendix B) a pure behaviour, lists of input and output parameters andbehaviour incompatibilities, triggering conditions, a daemon and a behaviourstatus representation. Note that in Figure 7 the extended behaviour is thestructure included in the big hexagon, and surrounding it are represented inputand output representations (pale yellow, connected by thin arrows), anincompatible behaviour (small hexagon, connected by a dashed arrow), and atrigger representation (pale maroon, connected by a thick arrow). Theseconventions for arrows will be used throughout this paper, as well as usinghexagons for behaviours and rectangles for representations.
53
We will now describe and justify each component of the extendedbehaviour, and show how this wrapping provides the flexibility argued forbefore.
Figure 7. Structure of a behaviour envelope
4.2.1 The Pure Behaviour
The pure behaviour (blue in Figure 7) is the code that implements thedesired functionality by reading input from one or more representations,performing its task, and writing the results into one or more (may be the same)representations. Thus, a pure behaviour corresponds to the SMPA part of theSMPA-W cycle defined by S*. Since the basic units that the mission
54
specification language deals with are behaviours and representations, and thereare no language constructs that manipulate the internal structure of a purebehaviour, this structure is not relevant in the discussions that follow, so wewill treat the pure behaviour as an atomic entity. Still, it is important toremember that this is just a convenient approximation in the context of thiswork, and the reader is pointed to important discussions on the structure of S*behaviours in [Tsotsos{ XE "Tsotsos" } 1997, Tsotsos 1995b, Tsotsos 1996]and [Rotenstein 2002].
4.2.2 Behaviour Parameters
A mission configures a network with a particular topology, anddepending on this configuration, the same pure behaviours and representationscan implement different overall functionality. To allow the flexibility necessaryto accomplish this, the pure behaviours and representations need to bedecoupled, i.e. the pure behaviours should not make direct, hard-codedreference to any representations, but instead go through an intermediate datastructure, a list of representations (yellow in Figure 7). This list is set up as partof the network specification, and introduces an extra level of indirectionbetween the code and the data. For clarity, the list of representations that a purebehaviour needs is split into an input list, containing pointers to all therepresentations that the behaviour reads from, and an output list, containing allrepresentations that the behaviour writes to. Of course, overlap between the twois possible, the separation being somewhat artificial.
55
4.2.3 Daemons
In order for behaviours to execute, changes in relevant representationsmust be detected, and this task is accomplished by daemons that act as triggersfor the otherwise dormant behaviours (grey in Figure 7). Since it is theconnection between daemons and the representations that they monitor thatdefines the control flow through the system, they need to be flexible and theuser needs to be able to configure these connections without modifications tothe pure behaviours or to the daemons. This is accomplished by associatingwith each daemon a list of representations to monitor (maroon, marked“Triggers” in Figure 7). The structure of this list is identical to the parameterlists presented above. Due to the uniform representation, the daemonmechanism handles both internal and external changes in the same manner.Since daemons must not introduce long latencies and overhead, as a generalrule the code in a daemon performs a simple test, such as “has therepresentation I’m interested in changed since the last execution of thebehaviour,” it is up to the behaviour itself to implement code that verifies thatthe changes are relevant, if appropriate. In this implementation, only daemonsthat monitor representations for changes have been provided, but through reuseof the mechanism that evaluates the Boolean expressions presented in sub-chapter 3.1.4, significantly more complex trigger conditions can beimplemented if desired. We will see below how the daemon monitoring arepresentation mechanism can be used to implement temporal constraints.
56
4.2.4 Behaviour Status
The complexity of possible interactions between behaviours requiresthat the behaviour envelope provide a status representation (green in Figure 7)that can be observed by other behaviours and/or daemons. The statusrepresentation encapsulates information about whether the behaviour is runningor not, did the execution complete, was it successful, etc. Also, if the mutualinhibition behaviour integration scheme is used, the status representationindicates whether the behaviour has been inhibited, and stores the informationneeded to resolve ambiguities that can result when several behaviours issueinhibition/reactivation requests.
4.3 Nested Ensure Clauses
It is obvious from the description of the language that while-ensuregrouping constructs can be nested, and this raises the question of solving thepotential incompatibilities and inconsistencies, and integrating the differentpredicates present in the ensure clauses. The issue is complicated significantlyby the fact that behaviours at different nesting levels can execute in parallel.
We identify two different execution circumstances, each with specificrequirements; we will analyze them and investigate possible solutions. If thestructure of the mission is such that behaviours belonging to the outer while-ensure clause can’t execute in parallel with the inner while-ensure, behaviourscan be inhibited and/or activated allowing the inner ensure clause to takeprecedence. For the Boolean predicates, we could attempt to merge the levels,so that the inner loop evaluates a compound expression, but unfortunatelywithout semantic information it is impossible to determine which conditionsshould take precedence in case a test involves the same representation, and
57
mandating an arbitrary scheme leads to unpredictable and inconsistentbehaviour, so we need to declare the inner one to take precedence, effectivelyshutting off the evaluation of the outer expression, and asking the missiondeveloper to provide complete sets of conditions with each ensure clause.
The situation is significantly more complex in case outer behaviours canexecute in parallel with the inner while-ensure behaviours, because behaviourscan’t be inhibited and active at the same time, and we can’t shut off theevaluation of the outer Boolean predicate. In this case the presence ofconflicting behaviour requirements can’t be resolved in favour of the inner set,and this condition must be identified and flagged as an error by the networkbuilding process. The solution presented above for the different Booleanexpressions, i.e. mandating complete predicates at each level is still needed, andthe task of deciding what action should be taken in case of a failure has to beaccomplished by the exception handling mechanism. This is a strong argumentfor the integration of the exception handling mechanism into the language, inthe form of a try-catch type construct, allowing for customized actions that canbe attached to specific groups of behaviours and mission stages.
4.4 Behaviour Life-Cycle
58
A number of critical events occur in the lifecycle of a behaviour, wewill now detail them and show their place in the two execution modes, purelyreactive or mission based.
The lifecycle of a behaviour begins with its activation, at which point asystem thread is allocated from a thread pool and the daemon begins executing.The daemon reads the list of precondition representations (the "trigger"representations) and monitors them for changes. This is a daemon in itssimplest form, dictated by the desire to make them simple, fast, and with lowoverhead, of course by reusing the while-ensure Boolean expression evaluationmechanism significantly more complex preconditions can be tested, but thiswould require significant additions to the mission specification language andwas not investigated here.
For behaviours involved in complex temporal relationships defined by amission, the same triggering mechanism works without any change, it is justimportant to add the appropriate status representations to the list of triggerrepresentations.
When the pure behaviour's preconditions are met, the daemon will startit. Three tasks have to be completed during this start, namely sending outinhibition requests (or implementing whatever a-priori behaviour integrationscheme is desired, if any), verifying that the temporal preconditions have beenmet, since the daemon only monitors updates to representations, and not theirnature, and verifying that the changes detected in the triggering representationsare relevant. For each, a few options exist as to where the code should belocated, each with pros and cons; they will be discussed with theimplementation (Chapter 5).
Since, as mentioned, the daemons have limited decisional capabilities,the first task of the pure behaviour is to ensure (if needed) that the changesdetected by the daemon are relevant. If the conditions are not met, the purebehaviour will return control to the daemon, and the daemon will continue
59
monitoring the preconditions. If the pure behaviour decides to execute, theappropriate parameters are read from the list in the envelope and the code isexecuted. After one SMPA cycle, control is returned to the daemon after settingthe relevant status flags.
The framework presented here addresses a number of limitationspresent in most behaviour-based systems, and in particular the separation of thepure behaviour (i.e. the code that performs the desired function) from itstriggering conditions and input/output representations allows the system totackle complex problems, containing temporal sequences, in a consistent andflexible manner.
4.5 Example
Two types of examples will be presented throughout this paper. Thefirst category illustrates the fact that S* can implement behaviour-basedsystems, and these examples are used mainly to illustrate the constructsinvolved in the behaviour networks in a familiar setting. The second categorywill be examples of missions, illustrating the process of converting missionprograms into behaviour networks.
To review, in this and other similar figures that follow, behaviourenvelopes are represented by hexagons (so each hexagon’s structurecorresponds to Figure 7), and representations by rectangles. A solid arrowfrom a behaviour to a representation signifies that the behaviour writes to therepresentation. A thin solid arrow from a representation to a behaviour meansthat the behaviour reads from the representation, while a thick arrow meansthat the behaviour is triggered by changes in the representation (and also readsfrom it). A dotted arrow between two behaviours means that the source
60
behaviour inhibits the destination behaviour. As a first simple example, let usconsider a “bump-and-turn” navigation controller, presented in Figure 8.
Two representations are needed, one for the collision sensors and onefor the locomotion system (in this case, as in all the examples in this work, asimulated differential drive was used). The default behaviour of the robot(Wander) is to drive forward at a constant speed. The Collide behaviour’sdaemon monitors the collision sensor representation, and when a change isdetected, the default behaviour is inhibited and avoidance moves are performed.
CollisionSensor
Wander(default)
Collide
Locomotor
Figure 8. Simple Example - bump-and-turn (dottedline indicates inhibition)
These involve sending commands to the locomotor representation tomove away from the obstacle, then turn a random angle in a random direction(this is accomplished by sending different commands to the two wheels of thelocomotion system for a random time, but it could also be accomplished at ahigher level, instructing the locomotor to turn the robot a specified number of
61
degrees). After the turn, the Collide behaviour terminates and the defaultbehaviour is reactivated.
While very simple in nature, it is very easy to see how the addition oftwo representations (one for a map and the other for the current robot location)and one behaviour (map updating) could transform this into a robot that buildsa map of its environment, by having the extra behaviour mark the location ofthe obstacle on the map.
62
Chapter 5 Implementation and Experimental Results
In implementing the system presented above, a number of designdecisions were taken, they will be presented and justified as appropriate. At thehighest level the process of converting a mission into a network of behavioursconsists of three steps:
- Parsing of the mission program and translating it into an intermediaterepresentation
- Determining the complete set of behaviours and representations
- Generating the behaviour network
First we will present these three steps in detail, introducing the tools thatwere used and the data structures that were designed, and justifying designdecisions. Secondly, we will discuss how some of the problems presentedearlier have been solved, such as the implementation of temporal constraints,the nesting of while-ensure constructs, etc. Following this, we will present anumber of examples implemented in the course of this research, starting withstatic networks that illustrate the general capabilities of S* and continuing witha number of missions and a presentation of the intermediate steps in each case.
63
The examples will be discussed and the conclusions drawn will highlight somelimitations of the language in its present form.
5.1 Parsing: From Missions To Intermediate Representations
Transforming a mission program into a network{ XE "network" } ofbehaviours is a complex process, and doing it in two steps helps manage thiscomplexity, but at the same time creates the necessity for intermediaterepresentations that correspond to the extended behaviours presented above.We will call these “behaviour network node descriptors,” and the intermediaterepresentation is a graph that connects these. The structure of this graph closelymimics the structure of the behaviour network.
First we will present the behaviour network node descriptors and thegraph they form, then we will describe the parser{ XE "parser" } and how itgenerates the graph.
5.1.1 Behaviour Parameters – Numeric Parameters
As seen in 3.1.5, we have restricted behaviour parameters to threepossible types: numbers, representation names and symbols. We will now seehow each is implemented and discuss some implications of these designdecisions.
Numerical parameters are needed to express commands such as
64
turn camera (45);and move forward (10);
To keep within the spirit of S*, these values need to be stored inrepresentations, for this purpose we have introduced a SimpleRepresentationclass, with the sole purpose to store numerical values. We also define anabstract class named ComplexRepresentation that needs to be subclassed toprovide any required data storage services (i.e. representations that store morethan just a number). Both classes inherit from another abstract class namedsimply Representation, that provides the basic locking services presentedearlier. SimpleRepresentation is instantiated whenever a new numericalparameter appears in the mission, and the behaviour node descriptor stores apointer to it in its parameter list. Of course, other solutions are possible, andthey fall into two broad categories:
- Behaviour-specific parsing: the parser identifies the behaviour, andbased on information provided by the system, identifies the appropriaterepresentation and data item within the representation and inserts thevalue.
- Special-case code that stores numerical parameters somewhere in thesystem, and retrieves it whenever appropriate (e.g. at the behaviour’srequest)
The former solution has a number of serious problems, perhaps themost serious being the fact that since the value is set when the mission isparsed, i.e. very early in the execution cycle, there is no guarantee that therepresentation will not be changed during the execution of the mission. Also theprocess of identifying the appropriate representation is not as simple as it mayseem, having to resolve ambiguities based on information that might not beavailable until runtime. The latter solution is even less palatable, being verymuch in contradiction with the spirit of S*, and also presenting seriousproblems from a software engineering point of view. It is a testament to the
65
expressive power of the S* framework that in the course of this research hehave been able to entirely avoid the use of special-case code, and we were ableto express all the concepts within the framework.
5.1.2 Behaviour Parameters – Representation Names As Parameters
Using representation names as parameters is very much in the spirit ofthe language as originally presented, making the language very consistent withthe structure of S*: functional constructs are behaviours (as proposed originallyby [Tsotsos 1997]), data constructs are representations. This solution relies onrepresentations being implemented as singleton (i.e. single-instance) classes,and as such, the name of a representation class uniquely identifies therepresentation to be used. The main disadvantages of this approach are the factthat it exposes the internal organization of data to the mission programmer,which is not desirable since the goal is to have the missions programmed byscientist who don’t need (and should not need) to know such details, and thefact that the solution can not be applied in case the singleton representationparadigm is abandoned. A more subtle consequence of this approach has to dowith the granularity of representations. If we use high-level, complexrepresentations, it is very likely that we will need parameters that referencesubstructures of these, and we have no mechanism to accomplish that. On theother hand, a high granularity of representations means that it is very unlikelythat the singleton solution is appropriate, multiple instances of low-level datastructures being needed to represent objects that appear repeatedly in theenvironment (e.g. a list of landmarks or targets).
5.1.3 Behaviour Parameters – Symbolic Parameters
66
The problems revealed above have led us to investigate a secondsolution for the representation of behaviour parameters in the language, namelythe definition of high-level symbols that are parsed and translated intoappropriate data pointers. While this may seem little more than syntactic sugaron top of the previous solution, a number of advantages are immediatelyapparent. High-level symbols allow mission scientists to describe missions intheir own domain-specific language, without having to bother with S*implementation details, the solution does not require the representations to besingletons, providing flexibility for future investigations, and is a good fit forhierarchical representations, where a symbol can be translated into a pointer tosub-representations at any desired level. The disadvantage of this approach isthe fact that it relies on a translation process and on the arbitrary definition ofsymbols for particular application domains, which reduces the portability ofmissions.
While two different solutions have been investigated, each with anumber of advantages and disadvantages, as will become apparent, the twosolutions are not incompatible, they can coexist in the language specificationand allow both the desired low-granularity of representations and access to theirinternal structure. The art of system design rests in deciding when to use each,and finding the appropriate balance between the two. An innovativehierarchical organization solution to the granularity of representations isproposed in [Rotenstein 2002], a solution that seems to provide a formalframework for the organization of representations, and thus provides answers tothe questions raised above. Once the theoretical aspects of this proposal havebeen completed, it will be important to integrate that approach with the missionspecification language.
5.1.4 Behaviour Network Node Descriptors
67
The intermediate graph nodes encapsulate information about the type ofnode, the identity of the node, its parameters and the temporal relationships it isinvolved in. We will describe each in the following paragraphs.
Nodes in the intermediate representation can be of several types,corresponding to the various language constructs. Thus, we have behaviournodes representing extended behaviours, storing information about the identityor type of pure behaviour and lists of input and output parameters identical tothe ones presented in 4.2.2. Phase nodes are simple place-holders for thebehaviours defined as part of the phase and While nodes, similarly, as place-holders for the behaviours defined as part of the while-ensure{ XE "while-ensure" } construct, but also storing all the information about the content ofthe ensure clause{ XE "ensure clause" }. Also, to facilitate the representationof common merger and divergence points, such as for example the start and endof a phase, Start and End pseudo-nodes are defined. These do not store anyinformation, and are mainly used as anchor points for the behaviours withinphases and while grouping constructs.
Each node (with the exception of the Start and End nodes) has anidentity, with the Phase and While nodes labelled by the name given to them inthe program, and the behaviour nodes labelled with the name of the behaviourclass.
Also, each node in the intermediate graph has lists of nodes it is intemporal relationships with, forming a doubly linked graph of nodes. Theforward links are used to traverse the structure in order to generate thebehaviour envelopes, while the backward links serve as the basis forautomatically generating the trigger lists.
An important task of the parser{ XE "parser" } is to associate theensure-clause information to the while construct. As we have seen when thelanguage was introduced, there are three categories of information: a list ofbehaviours that need to run, a list of behaviours that need to be inhibited, and a
68
Boolean expression that needs to be periodically evaluated for the duration ofthe while-ensure{ XE "while-ensure" } clause, and While pseudo-nodeshave appropriate data structures to store this information. The Booleanexpression is transformed into a tree with representations and values as leavesand comparison and logical operators as nodes. This tree is in the formatexpected by the BooleanExpressionParser class, its role being to traverse thetree and evaluate the expression; so no further processing of this data structureis needed. As mentioned earlier, if desired this class could be reused fordaemons that implement complex triggering conditions, but that possibility isnot explored in this work.
The parser{ XE "parser" } is implemented using the standard Lex andYacc tools, and it reads a mission specification and transforms it into a graph ofbehaviour network{ XE "network" } node descriptors. The grammar ispresented in detail in Chapter 3 and in Appendix A. The parsing process isfairly straightforward; the only complication being introduced by the fact thatphases and while-ensure constructs can be used repeatedly. This issue is dealtwith by inserting every phase and while-ensure definition into two tables, andwhenever a phase or while-ensure are used in the mission, the definition isretrieved and a copy is placed in the graph. This inlining is the natural solutionin the context of an S*{ XE "S*" } controller, treating them as out of linesequences (i.e. similar to a function call) would be very awkward and introducean unnecessary level of complexity in the control flow, while at the same timemaking it very difficult to associate the execution of the behaviours with thevalidation of the associated ensure clauses, especially since the same groupscould potentially be executed as part of different while-ensure{ XE "while-ensure" } constructs at the same time. Also this simplifies any future efforts toadd mission validation code. One limitation is introduced by the fact that theparsing is single-pass, and thus it is not permitted to use a symbol before itsdefinition. This restriction is captured in the grammar, and appropriate errorwill be generated if the user attempts to do this. Another limitation introducedby the inlining is the fact that it prohibits recursive grouping constructs.
69
5.1.5 Parameters In Node Descriptors
We have introduced in 4.2.2 the notion of lists of input and outputparameters. Here we will detail the process of transforming a list of missionparameters into the list of parameters associated with a behaviour descriptornode. Since behaviours and representations can be used in applications in ahard-coded fashion, as seen in 4.4, and also since the link between certainbehaviours and representations is unlikely to change (e.g. the link betweenmotion behaviours and the associated actuator representations, the link betweencertain sensor representations and the associated behaviours, etc.), eachbehaviour needs to know what its default parameters are, and a missionprogram only needs to provide the parameters that are different. Since it isdifficult to know in the behaviour design stage which parameters are going tobe fixed and which under mission control, we have decided to use the followingsimplifying convention: in the list of parameters, the mission developer canomit parameters that are identical to the hard-coded value, and replace themwith a “null” parameter (similar to the concept of default parameters inprogramming languages such as C++). Following a general convention, defaultparameters at the end of the list can be omitted, so when all the parameters havetheir default value, an empty parameter list can be provided. As mentionedbefore, each behaviour node descriptor has a list of parameters, this will befilled in by the parsing process with pointers to the appropriate data structures,or with null pointers, and the second stage of network generation will resolveany conflicts and ambiguities when creating the extended behaviour.
5.1.6 Networks Of Node Descriptors
70
As mentioned before, we have decided to break the network buildingprocess into two steps, first transforming the information from a missionprogram into an intermediate representation, and then going from this to thedesired network of behaviours.
Figure 9 provides an example that should illustrate the information inthis subchapter. The mission that is parsed into the graph omits behaviourparameters and concentrates on the temporal connections between nodes and onthe use of pseudo-nodes. In the mission, behaviour and representation names,being irrelevant in this context, have been abstracted out and replaced by B’sand R’s, respectively, and V’s have replaced numeric values. To clarify therelationship between the mission and the graph we add an index to eachsymbol.
startphase P1 { B1(); [B2 (), B3 (), B4 ()); B5 (); B6 ();}while W1 { B7 (); P1; B8 (); phase P2 { B9 (); P1; B10 (); }; B11 ();} ensure (B12 () && B13 () && !B14 () && !B15 () &&R1>V1 && R2<V2 && R3>=R4)end
71
In figures representing intermediate graphs arrows represent temporalconnectors, using the following convention: regular arrows, double arrows anddotted arrows representing, respectively, followed_by, starts_with andends_with relationships.
Figure 9. Graph of behaviour network nodedescriptors. B – behaviours, R – representations, V– numeric values, S/E – Start/End pseudo-nodes,W – while-ensure pseudo-nodes, P – phasepseudo-nodes. Numbered boxes are described inthe text.
72
Box 1 represents the high-level structure of the mission: a Start node,followed by a While node, followed by an End node. The While node hasassociated with it the Boolean expression to be evaluated (box 3) and, throughtemporal connectors, the behaviours that need to run at the same time as theWhile node (box 2a, connected by starts_with and ends_with connectors).The list of behaviours that need to be inhibited for the duration of the While isalso stored (box 2b), but no temporal connectors are used. A solution needs tobe found to include the evaluation of the Boolean expression, the execution ofthe required behaviours and the inhibition of the incompatible behaviours, allwithin the normal S* framework, if at all possible. We will deal with this issuewhen generating the network of behaviours.
Boxes 5 and 7 are the two instances of the P1 phase (a behaviour,followed by three behaviours that start in parallel, followed by two consecutivebehaviours), inlined in the graph as described above, while box 6 is phase P2 (abehaviour, followed by a phase, followed by a behaviour). Box 4 represents thehigh-level structure of the while-ensure construct (behaviour – phase –behaviour – phase – behaviour). To aid in synchronizing the variouscomponents, each stage is enclosed in a pair of Start and End nodes.
5.2 From Intermediate Representations To Networks Of Behaviours
The process of transforming the intermediate graph into a behaviournetwork{ XE "network" } involves a traversal of the graph and the generationof the appropriate behaviour envelopes. For the most part this is a straight-forward and intuitive process, the only interesting aspects being the handling ofthe behaviour parameters and the conversion of the list of behaviour nodes
73
associated with an ensure clause{ XE "ensure clause" } and the evaluation ofthe associated Boolean expression.
5.2.1 Behaviour Parameters
Behaviours are initially built with their default parameters, a task that isaccomplished by the default constructor of the behaviour envelope class. Thereal parameter list from the intermediate representation is scanned for non-nullentries. These will replace the defaults and thus the behaviours are fullyprepared for execution.
5.2.2 Start/End Pseudo-Behaviours
One design decision was to translate the Start and End pseudo-behaviour descriptor nodes into special Start and End behaviours that do(almost) nothing, simply exit marking successful completion in their statusrepresentation, and are used for synchronization purposes. This has been donein order to have singular entry and exit points from grouping constructs, aidingin the understanding and debugging of the process. The “almost” in thepreceding statement refers to the fact that these pseudo-behaviours have nofunctional role, but they contain debugging code that is very useful in the
74
development of new missions. For the sake of functional efficiency, anoptimization module will be added between the two stages, to eliminate thesepseudo-behaviours, but at this point the need for the debugging help that theyprovide prevailed, and they have been kept in the final design. Probably thebest solution is to provide an option that allows programmers to selectivelyinclude and exclude these, similar to the debug and optimized modes oftraditional compilers.
5.2.3 Compatible Ensure Clause Behaviours
As far as the conversion of the lists of behaviour nodes associated withan ensure clause{ XE "ensure clause" } is concerned, in order to bring thesenaturally within the S*{ XE "S*" } framework, a simple solution was designedand implemented, that solves three problems simultaneously. The solutionstems form the need to have a process that executes periodically evaluating theBoolean expression in the ensure clause. The simplest and most natural solutionis to create a While-ensure behaviour. This behaviour has a single task, namelyto evaluate the Boolean expression, and if the evaluation fails, it will generatean exception. Since the S* exception handling mechanism is still in early stagesof design and implementation (see [Rotenstein 2002] for details), this isaccomplished by simply creating an exception record and inserting it in a queueof exceptions, after which the execution continues. This will change once theexception handling mechanism is in place, and our code will simply inherit thefunctionality needed, with minimal (if any) changes. The While-ensurebehaviour is connected by a starts_with type connection to the associatedStart behaviour, and by an ends_with connection to the associated Endbehaviour, and thus the While-ensure behaviour will execute in parallel withall the behaviours that make it up, and end with them. The introduction of thisbehaviour brings the ensure behaviours nicely into the S* framework.
75
5.2.4 Prohibited Ensure Clause Behaviours
As mentioned before, the sequence of behaviours within a while-ensure{ XE "while-ensure" } clause is encoded between a Start and an Endpseudo-behaviour. The prohibited behaviours are listed on the While-Ensurepseudo-behaviour's inhibition list, so it will transparently send out the inhibitionrequests at the beginning and the activation requests at the end of its execution.This ensures that no prohibited behaviours will be triggered, either in a purelyreactive fashion, or as a result of changes to representations during theexecution of the behaviours contained in the while-ensure clause. Thebehaviours that must run while the while-ensure clause{ XE "ensure clause" }is executing are simply linked through "starts-with" links to the while-ensureStart pseudo-behaviour and with "ends-with" links to the End pseudo-behaviour. Thus, with the introduction of three pseudo-behaviours, all aspectsof the language are naturally integrated in the S* framework, and no special-case code has to be written.
5.3 Building the Complete Behaviour Network
The process of determining the set of behaviours that constitutes asolution from a mission specification is fairly straight forward, due to the natureof the mission-specification language, which uses the behaviours themselves as
76
part of the mission specification. This takes care of the planned part of amission, but these behaviours might require supporting behaviours as part ofthe reactive part of the mission in order to execute properly. The methodproposed by [Tsotsos 1997] for determining this set of supporting behavioursfor a given robot can be adapted to our needs. First, the generic process: foreach sensor and actuator representation, all the behaviours that read from andwrite to them are included, as well as the arbitration behaviours if needed; forthese behaviours, all referenced representations have to be included, and so on.To this, we add all the mission-specified behaviours (including behavioursspecified in the ensure clauses – if any), create a list of representations thatthey read from, for these, locate the behaviours that write to them and includethem in the mission. Continue the process until all required behaviours andrepresentations are included. Perform a similar process for the representationswritten to. Thus the behaviours, connected through representations andtemporal constraints, form a directed graph. If we add to each node a worst-case cost, proof theoretic methods can be applied in order to guarantee missiontiming specifications, one of the most important items of future work.
The process of gathering all this information for a given application isencapsulated in the SController class, with subclasses for individualapplications (see Figure 23 in Appendix B). In mission based applications, thecontroller also initiates the process of parsing the program and building thenetwork, and also keeps track of the system’s default behaviour and ensuresthat it is placed in the network with the appropriate temporal connections.
5.4 Behaviour Life-Cycle – The Implementation
We have seen earlier that a number of critical events occur in thelifecycle of a behaviour, we will now provide details on the implementation ofthose concepts.
77
The lifecycle of a behaviour begins with its activation, at which point asystem thread is allocated from a thread pool and the daemon begins executing.In purely reactive configurations, all daemons have to execute in parallel at alltime, so threads are allocated at system startup, and no further action needs tobe taken until shutdown. In mission-based configurations, which tend to havelarger numbers of behaviours, this can become a problem, due to the heavydemand that threads put on a system. We distinguish two types of behaviours,based on how they were included in the system: behaviours explicitly specifiedin the mission program and supporting, reactive behaviours included based onthe iterative procedure described in 5.3. For the latter, the same principleapplies as for purely reactive systems, the associated daemons need to executeat all times. In the former case, due to the existence of temporal constraints, theorder of activation is predictable, and so reuse of threads is not just possible, butactually recommended, and the idea is that whenever a behaviour startsexecuting, all the behaviours that have temporal connections to it are activated(i.e. are assigned a thread and the daemon starts executing). When a behaviourcompletes its task, the thread is returned to the thread pool and the behaviour isdormant until reactivated.
Daemons read the list of precondition representations (the "trigger"representations) and monitor them for changes. Once changes have beendetected, two tasks have to be performed before the pure behaviour can executeits main functionality. The first task, relevant only for mission-basedconfigurations, is to verify that the appropriate type of temporal relationship issignalled by the detected change in another behaviour’s status representation.This code was implemented in the behaviour envelope, to facilitate code reuseand also because conceptually this in not a type of task that a pure behaviourshould be responsible for. The test itself is trivial, and it involves matching theappropriate flags in the status representation with the expected values for thegiven temporal constraint, and also the timestamp if the relationship involves adelay (e.g. for start after <time> constraints). The second test that needs to beperformed is on the triggering representations themselves. Since the daemon
78
only detects change in representations, and not the nature of the changes, itmust be verified that the changes are relevant, and this task is accomplished bythe pure behaviour, this being its area of expertise and all the informationnecessary to take the appropriate decision should be available to it.
Also at this time inhibition requests need to be sent out, and again thistask is delegated to the behaviour envelope. It was mentioned before thatinhibition requests have to be matched, this is accomplished by adding to thestatus representation a simple counter, each inhibition request increases thecounter, each reactivation request decreases the counter, the behaviour isreactivated only when the counter reaches zero. If the application demandsmore complex matching schemes, they can be easily implemented on top of thismechanism by sub-classing the status representation and behaviour envelopeclasses and overriding the appropriate functions.
When the pure behaviour completes one cycle of execution (i.e. anSMPA cycle), before control is returned to the daemon a number ofhousekeeping tasks have to be performed, namely setting the status flags, doneby the pure behaviour, and sending reactivation requests, again implemented inthe behaviour envelope, like the inhibition. It is also the behaviour envelope’srole to handle inhibition and reactivation requests from other behaviours.
5.5 Experimental Results
79
A number of behaviours have been implemented at various levels ofabstraction, ranging from collision and obstacle avoidance to visually guidednavigation and target tracking. These behaviours have been chosen mainly forthe purpose of illustrating the capabilities of the system, they are in no wayrepresentative of behaviours that would have to be implemented for anymission on a real robot, and similarly the problems that are solved by themissions are simple toy problems.
Several missions have been implemented, some in pure behaviour-based fashion (of course, augmented by the availability of internalrepresentations) and some mission based, illustrating the flexibility of theapproach and proving the fact that planned missions and behaviour basedsystems are not incompatible, and even more, that the S* framework naturallyintegrates the two, without any need for special constructs or code. Therepresentations used and the controllers implemented are presented in Figures22 and 23 in Appendix B. To our knowledge this is the first demonstration of aplan-guided behaviour-based system that does not require a hierarchicalarchitecture.
5.5.1 Behaviour-Based Target Tracking
A simple example of a behaviour network is presented in Figure 10,using the conventions introduced in subchapter 3.3. The task consists in thevisual identification of a target, followed by the motion of the robot towardsthe target while the target is tracked by the camera system. The task isexecuted repeatedly for all the targets contained in a list of targets. Therepresentations used are:
- TargetList - contains the list of targets that need to be located andanalyzed.
80
- CurrentTarget – contains a description of the current target (colour,location, status information- e.g. was it aquired, was it analyzed, etc)
- StereoCameraImage – contains the stereo images captured from thecamera system both in raw and processed format
- CameraMast – actuators needed to direct the camera, also containsinformation about the position and orientation of the camera systemand the
- Locomotor – actuator for the robot’s differential drive system
GoToTarget
LocomotorCameraMast
CurrentTarget
TargetList
TrackTarget
ScanForTarget
SelectCurrentTarget
UpdateTargetList
StereoCameraImage
Figure 10. Simple example - target tracking andanalysis
81
The behaviours used are:
- SelectCurrentTarget – reads the description of the target at the top ofthe target list and updates the CurrentTarget representation
- ScanForTarget – reads the description of the current target and thecurrent stereo images and directs the camera mast to rotate, searchingfor the target
- GoToTarget – reads the description of the current target and thecurrent stereo images and directs the locomotor to move the robottowards the target
- TrackTarget – reads the description of the current target and thecurrent stereo images and directs the camera mast to rotate, keepingthe target in the field of view
The process is started by the daemon of the SelectCurrentTargetbehaviour, which detects that the TargetList has been updated (initialized).The behaviour reads the description of the first target and initializes theCurrentTarget representation accordingly (e.g. it declares that the currenttarget is red). The ScanForTargetBehaviour is triggered, and based on theinformation in CurrentTarget it writes to the CameraMast representationinstructions to turn the mast, analyzing the resulting image for red objects.The process continues until a red object is found and centred in the field ofview (for simplicity, we will omit the behaviours that get triggered in case thetarget is not located after a full 180 degrees scan, two alternatives have beenimplemented: a behaviour that selects the next target descriptor in the list,while the current target descriptor is reinserted lower in the list for later
82
processing, or a behaviour that starts wandering randomly in the environment,looking for the target). Once the target is centred, the behaviour marks thetarget as "acquired" and stops.
The "acquired" flag triggers the TrackTarget and GoToTargetbehaviours through their respective daemons, and these will (in parallel)move the robot towards the target and try to keep the target in the centre ofthe field of view. If the target is lost, the process goes back to ScanForTarget.GoToTarget monitors the distance to the target via the depth informationprovided by the stereo camera system, and when the distance gets below apredetermined value, the target is marked "analyzed" and TrackTarget andGoToTarget terminate. The change in the status of the target is detected bythe UpdateTargetList behaviour, which makes the next target descriptoravailable in the TargetList, and the process starts again.
5.5.2 Behaviour-Based Target Tracking with Mutual Inhibition
For a slightly more elaborate example, we will augment the simpletarget detection and tracking system presented above to handle collisions, thusillustrating the inhibition between behaviours. The mission proceeds asdescribed previously, with an additional representation and behaviour pair (seeFigure 11). The added representation corresponds to the robot's collisionsensors and the Collide behaviour is triggered by changes in this representation.The associated daemon checks the incompatible behaviour list, and sends allthe instances of the GoToTarget behaviour an inhibition request beforetriggering. Based on the particular collision sensors that have been activated, aseries of evasive motions is performed in order to clear the obstacle. Once thesemotions have been completed, the behaviour stops and GoToTarget isreactivated.
83
GoToTarget
Locomotor CameraMast
CurrentTarget
TargetList
TrackTarget
ScanForTarget
SelectCurrentTarget
UpdateTargetList
CollisionSensor
Collide
StereoCameraImage
Figure 11. Simple example - target tracking andanalysis with collisions (dotted line indicatesinhibition)
More elaborate examples of the capabilities of S* can be found in[Rotenstein 2002], including integration between planning and reactivebehaviours, the role of task information in attentive processing, andinvestigations on behaviour integration.
84
5.5.3 Mission-Based Target Tracking – Three Examples
Moving on to demonstrating the capabilities of the mission specificationlanguage, we will present three variations on the target detection and trackingexample, all based on externally provided programs, instead of the hard codednetworks used in the previous examples.
The first mission is an extension of the mission presented in Figure 10(where we presented the underlying behaviour network nodes). The task is toidentify three targets, and move towards them while they are tracked by thecamera system.
start
while W1 { B_SelectCurrentTargetBehaviour(); B_ScanForTargetBehaviour(); [ B_GoToTargetBehaviour(), B_TrackTargetBehaviour() ); B_UpdateTargetListBehaviour(); B_SelectCurrentTargetBehaviour(); B_ScanForTargetBehaviour(); [ B_GoToTargetBehaviour(), B_TrackTargetBehaviour() ); B_UpdateTargetListBehaviour(); B_SelectCurrentTargetBehaviour(); B_ScanForTargetBehaviour(); [ B_GoToTargetBehaviour(), B_TrackTargetBehaviour() );
85
B_UpdateTargetListBehaviour();} ensure ()end
The program consists of three repetitions of the sequence (we adoptedthe convention that behaviour names should start with “B_” whilerepresentation names start with “R_”):
B_SelectCurrentTargetBehaviour(); B_ScanForTargetBehaviour(); [ B_GoToTargetBehaviour(), B_TrackTargetBehaviour() ); B_UpdateTargetListBehaviour();
The sequence starts with a new target being read from the target list andthe current target representation being initialized. When the selection behaviourcompletes and the current target representation is updated, the scanningbehaviour is activated. Once it has identified the target and centred it in thefield of view, the behaviour completes and GoToTarget and TrackTarget startat the same time, generating the combined behaviour of motion towards thetarget and target tracking. As in the previous examples, GoToTarget will markthe target “analyzed” and both behaviours complete, which is a signal forUpdateTargetList to activate and refresh the target list, and the processcontinues for three targets.
The intermediate representation, using the conventions introduced inFigure 9 is presented in Figure 12, while the resulting behaviour network ispresented in Figure 13. In the behaviour networks associated with missions thatinclude temporal constrains, we will explicitly represent the behaviour’s status
86
representation as a rectangle attached to the behaviour hexagon, in order torepresent the connections.
Figure 12. Intermediate representation for targettracking mission
In Figure 12, Box 1 represents the high-level structure of the mission,i.e. the While construct and the Start and End pseudo-behaviours, while Box 2represents the repeating sequence highlighted above.
A careful inspection of the behaviour network in Figure 13 shouldreveal the similarities between it and the network in Figure 10, which is notsurprising, since it is fundamentally the same mission, but with a layer ofcomplexity imposed by the temporal constraints. To ease reading andinterpretation, Figure 13 presents a subset of the real behaviour network,
87
including the high-level structure and one instance of the repeating sequence.Also, the Start and End pseudo-behaviours have been labelled with matchingnumbers to ease the identification of mission stages.
Start 2
Status
SelectCurrentTarget
Status
ScanFor
Target
Status
UpdateTarget
List
Status
Start 3
Status
TrackTarget
Status
GoToTarget
Status
End 3
Status
End 2
Status
Start 1
Status
While-ensure
Status
End 1
Status
. . .
TargetList
StereoCameraImage
CurrentTarget
CameraMast
Locomotor
Figure 13. Behaviour network for target trackingmission
In Figure 14 we concentrate on two repetitions of this sequence,illustrating the way multiple instances of the same behaviour are differentiated.The two repetitions are separated by a dashed diagonal line, Due to thecomplexity of the graph, we have decided to eliminate the top-level Start-While-End behaviours, and to only include temporal and triggeringconnections, eliminating reads_from and writes_to connectors andrepresentations that do not trigger behaviours (such as actuator representations).
88
Figure 14. Behaviour network for target trackingmission - multiple instances of a behaviour
It is easy to see from this example that the introduction of phases wouldgreatly simplify the program, making the mission more modular and easier toread, interpret and modify. Here is the same example, but this time the list ofbehaviours is defined as a phase:
startphase P1 { B_SelectCurrentTargetBehaviour(); B_ScanForTargetBehaviour(); [ B_GoToTargetBehaviour(), B_TrackTargetBehaviour() ); B_UpdateTargetListBehaviour();}
89
while W1 { P1; P1; P1;} ensure ()end
The graphs are similar to the ones in Figures 12-14, with the addition ofPhase nodes in the intermediate network and the associated Start and End nodesand behaviours throughout.
This example clearly illustrates one of the shortcomings of the languageas proposed by [Tsotsos 1997]: there is no language construct to expressrepetitive tasks. A conditional version of such a construct would also greatlyincrease the expressive power of the language by allowing missions to be statedas “repeat this sequence of steps until all targets have been analyzed.” Again,the Boolean expression evaluator could be reused to accomplish this task aspart of the While behaviour start up.
A third variation of this example makes use of the behaviourparameters, and while demonstrating the power of this language construct; itwill also expose another shortcoming of the language, namely the lack ofparameterized grouping constructs.
start
while W1 { B_ScanForTargetBehaviour(RED_TARGET); [ B_GoToTargetBehaviour(RED_TARGET), B_TrackTargetBehaviour(RED_TARGET) ); B_ScanForTargetBehaviour(BLUE_TARGET); [ B_GoToTargetBehaviour(BLUE_TARGET),
90
B_TrackTargetBehaviour(BLUE_TARGET) );} ensure ()end
In this example, the mission is to scan for the specified target, and thenmove towards it while tracking it. The parser detects the symbolsRED_TARGET and BLUE_TARGET, locates them in its symbol table andsimply translates them into pointers to the appropriate representations.
Of course, for this to work in the context of singleton representations,the code was modified to have one class per target, instead of the previouslyused generic CurrentTarget class. This solution is not desirable, since it impliesone class for every object that needs to be represented, so the second solutionproposed, that of symbolic parameters, has been implemented, and the targetsare selected from a “list of targets” representation through the use of a symboltable.
Figure 15 shows the behaviour network for the two phases, with the twotargets represented as components of the list representation.
91
Figure 15. Behaviour network for target trackingmission with parameters
When translating the graph of behaviour network node descriptors intobehaviour envelopes, this pointer replaces the default parameter for thebehaviours, so the whole process is transparent from the pure behaviour’s pointof view. For two targets it might not be more than a cosmetic issue, but if wewould like to expand this mission to many different targets, it would againmake sense to use a phase to describe the sequence of behaviours, butunfortunately the language does not permit the definition of phases witharguments.
92
5.5.4 Integrating Deliberative and Reactive Behaviours
Before demonstrating the capabilities of the ensure clause, we willdiscuss and illustrate the very important issue of the integration of deliberativeand reactive behaviours described theoretically in Chapter 4 through anexample based on the first mission presented in 5.4.3. The process ofgenerating a behaviour network includes a step that enumerates all the availablesensors. This process will identify the collision sensor and thus cause theCollide behaviour to be added to the network. Since the definition of theCollide behaviour identifies the GoToTarget behaviour as incompatible,whenever the robot collides with an obstacle, the GoToTarget behaviour will beinhibited, allowing for the obstacle avoidance steps to be taken withoutinterference (see Figure 16, based on Figure 13).
93
Start 2
Status
SelectCurrentTarget
Status
ScanFor
Target
Status
UpdateTarget
List
Status
Start 3
Status
TrackTarget
Status
GoToTarget
Status
End 3
Status
End 2
Status
Start 1
Status
While-ensure
Status
End 1
Status
. . .
TargetList
StereoCameraImage
CurrentTarget
CameraMast
Locomotor
CollisionSensor
Collide
Status
Figure 16. Inegrating reactive and deliberativebehaviours
At the same time, all the behaviours that are not identified asincompatible that are executing at the time of the collision (in this case thetarget tracking behaviour) will continue to execute. While this may not seemimportant, this feature is essential for the efficient functioning of the wholesystem, minimizing the side effects of reactive behaviours – in this case theobstacle avoidance would most likely cause the target to be lost, causing aneedless and potentially expensive new search for the target. Once the Collidebehaviour has completed, the GoToTarget behaviour is reactivated and themission continues.
94
5.5.5 The Ensure Clause
Since most reactive behaviours would be activated by unexpectedcircumstances (such as a collision with an obstacle) and their side effects couldhave significant consequences on the ability to complete the mission withinstrict time constraints, it is sometimes better to avoid them if possible. Ofcourse, reactive behaviours have an important role to play, especially inmaintaining the safety of the robot and its environment, but S* provides amechanism to “expect the unexpected” through the ensure clause. For example,in the previous example, it should be possible to avoid most collisions byspecifying in the ensure clause a minimum safe distance to obstacles, or bymandating the execution of a proximity sensor based obstacle avoidancebehaviour. The expressive power of the language allows us to even specifydifferent minimum distances for different stages of a mission by using multiplewhile-ensure constructs, each with different parameters, for example imposingstricter safety limits for the target approach stage, while relaxing them duringtarget analysis, so that the robot can approach the target to deploy its sensors.
Let us examine two possible solutions, based on the simple missionbelow:
start
while W1 { B_ScanForTargetBehaviour(RED_TARGET); [ B_GoToTargetBehaviour(RED_TARGET), B_TrackTargetBehaviour(RED_TARGET) );} ensure ()end
95
The mission consists in scanning for the red target, followed byapproaching the target while tracking it with the camera system. We can add anew behaviour, MaintainSafeDistance, that takes as its argument a minimumdistance from obstacles and invoke it as part of the ensure clause:
while W1 {...} ensure ( B_ MaintainSafeDistance(10.0) )end
Figure 17. Intermediate network for mission withan ensure behaviour
96
What this means is that the network will be set up such that theMaintainSafeDistance behaviour will be connected using starts_with andends_with temporal connectors to the While pseudo-behaviour, and that thefirst representation in the list of input parameters will be a simple representationwith a value of 10. The behaviour’s daemon will be active for the duration ofthe While pseudo-behaviour monitoring the proximity sensor representation,and it will instruct the locomotor to take evasive action whenever any obstacleis detected closer than the specified distance. Inhibition directed fromMaintainSafeDistance to GoToTarget ensures that there is no conflict betweenthe two behaviours, since they both try to write to the locomotor representation.For the purposes of this research we also investigated a particular instance ofthe behaviour cooperation, namely a vector summation scheme. TheGoToTarget and the MaintainSafeDistance behaviour both write to thelocomotor representation, but instead of imposing speeds for the two wheels inthe differential drive, they provide offsets from the current values, thuscontributing equally to the final setting. The GoToTarget behaviour steers therobot attempting to take the shortest distance to the target, while theMaintainSafeDistance behaviour will contribute an offset inverselyproportional to the distance to an obstacle that will steer the robot away, thusimplementing a simple form of behavioural fusion with goal-attractiondominance (see [Arkin 1998]). It is obvious from this example that bothschemes achieve the desired result, but the latter produces better results (at leastin this particular instance) since without the integration there is no way for theMaintainSafeDistance behaviour to know what the overall goal is, and so theevasive actions it takes might interfere with it, potentially causing the robot toget into an infinite cycle of approach and evasion. Figure 17 illustrates thisprocess, note that there are no inhibitory connections betweenMaintainSafeDistance and GoToTarget.
97
Figure 18. Behaviour network - ensure behaviour
A similar effect could be achieved by specifying in the ensure clausethat the readings from the proximity sensor should not exceed a minimumvalue, as in:
start
while W1 {...} ensure ( MIN_PROXIMITY>=10.0 )
end
98
S W E
>=
R 10
Figure 19. Intermediate network for mission withensure boolean predicate
In the parsing process, the symbol MIN_PROXIMITY is associatedwith the ProximitySensor representation, and namely with the pointer to thepiece of data that stores the minimum reading, i.e. the distance to the closestobstacle. The logical condition is evaluated repeatedly by the While-Ensurepseudo-behaviour. If the test fails, an exception is generated and it will behandled in as presented in [Rotenstein 2002].
99
Chapter 6 Conclusions and Future Work
6.1 Conclusions
This research provided a description of a virtual-reality environment formobile robot simulation, designed and implemented to support this and otherresearch. Its design, implementation and performance are presented anddiscussed in detail. Similar to other environments available in the commercialand research communities, our simulator provides real-time operation ofmultiple mobile robots, simulating the kinematics of the propulsion system andmotion constraints in the array of sensors. What makes our simulator unique isthe fact that it is geared towards research in vision-based robotics, simulatingthe view from on-board mast-mounted cameras, with the normal mechanicalconstraints imposed. A package of vision processing routines is available,allowing users to concentrate on high-level robotics tasks. Similar to NASA’sClaraty architecture, the simulator allows the behaviours to access the robot atdifferent levels of abstraction, from direct, low-level access to actuators to high-level commands to functional{ XE "functional" } units within the robot (i.e.camera system, locomotor, etc).
100
Also, we describe the “network{ XE "network" } of behaviours”concept. This concept, first described in [Tsotsos{ XE "Tsotsos" } 1997] isfleshed out for the first time, its important characteristics are described and theintegration between data-driven and temporal constrain type behaviourinterconnections is presented in detail, supported by experimental results.[Nicolescu 2000, Nicolescu 2002] and [Maes 1990] explore similar issuesrelated to the extension of the capabilities of behaviour-based systems via theintroduction of behaviour networks.
[Maes 1990] dynamically creates a network of behaviours from a givenbehaviour repertoire, and the action selection mechanism is based on spreadingactivation within the network from preconditions and goals, behavioursbeginning to execute when their level of activation exceeds a (dynamic)threshold. While the approach is very interesting and shows promise, it isunclear how reactive and deliberative aspects of a mission can be integrated,and no theoretical argument is made suggesting that such a system would havecapabilities exceeding those of traditional behaviour-based systems.
The architecture presented in [Nicolescu 2000, Nicolescu 2002] is, insome aspects, very similar to the S* notion of behaviour networks. Theirimplementation is also based on a separation of responsibilities betweenresponsibilities between modules that verify world and sequential preconditionsand modules that perform the actions (the terminology used distinguishesbetween “abstract” and “pure” behaviours). Activation flows through thesystem in much the same way as in traditional behaviour-based systems, withthe important addition of temporal constraints. The results presented arepromising, but while the architecture can ingeniously find solutions to simple,local problems caused by conflicts between behaviours, it is unclear how wellthe system can handle the complexities of real-world missions and how thesolutions proposed would scale to large systems.
The behaviour network concept presented in this work is in some wayssimilar to the ones investigated by these researchers, but the details of the
101
infrastructure for behaviour interaction we present are significantly moreflexible, being capable of accommodating all the levels of interaction, fromsimple behaviour-based interaction to mission guided, automatic generation ofnetworks, all within the S* framework, with little, if any special code to handlethe complexities introduced at each level. Even though it was not investigatedhere, our daemons can easily be adapted to implement Maes’ dynamicthreshold activation.
Finally, in the context of S*{ XE "S*" }, we have implemented amission specification language that provides support for task decomposition,synchronization and execution monitoring. This paper details the languageoriginally presented in [Tsotsos{ XE "Tsotsos" } 1997] and the structures thatsupport it at run time as well as introduce its first implementation. Examples arepresented.
In this process, a number of aspects of the language were clarified,some inconsistencies corrected and a number of limitations identified. Theoriginal definition of the language does distinguish between a declarative andan execution stage, this has been addressed in part, but the solution presentedhere is still incomplete, a better solution is proposed. Also, we formally definethe notion of prohibited ensure clause behaviours. The concept of behaviourparameters is extensively discussed, and pros and cons of various approachesinvestigated. Two solutions have been implemented, and it is observed that theyare not incompatible, each being more appropriate in certain circumstances.The analysis has revealed that the language lacks a few important features. Itdoes not have a clearly defined declarative stage, it lacks parameterizedgrouping constructs, and it does not permit the definition of explicit exceptionhandling mechanisms, relying instead on a predefined, hard-codedimplementation. Also, the language does not permit the definition of repetitivesequences, all repetitions have to be predefined and their number has to beknown at mission specification time.
102
6.2 Future Work
During this research, a number of additional extensions to the missioncontrol language have been identified and are proposed for future investigation.One important area where the mission language, and indeed, the whole S*{ XE"S*" } proposal, could be strengthened is the area of exception handling. Itwould be very useful to provide in the mission specification language forconstructs that would allow for structured exception handling, in the form oftry/catch blocks, with the mechanism reverting to the S* defaults in case thereis no explicit catch for the particular exception that is generated. This proposalhas major implications on the S* architecture, the whole exception handlingmechanism as presented in [Tsotsos{ XE "Tsotsos" } 1997] being still in earlyinvestigation and design stages [Rotenstein 2002]. Once that mechanism hasbeen implemented and analysed, and conclusions are drawn about itsperformance, potential and limitations, this proposal would become a naturalextension and topic for research.
Two areas of further investigation relate to the language itself. Thelanguage as implemented is fairly cryptic; the intention being that the planwould be automatically generated and maintained from higher-level goals anddescriptions. This aspect has not been investigated, all the tests being performedusing handcrafted mission descriptions. A set of tools to automate this processand to allow human operators to easily analyze, understand, modify andmonitor the execution of plans would be very useful. Depending on the futureuses of S*{ XE "S*" }, a more easily readable language might be desirable, theexamples presented in [Tsotsos{ XE "Tsotsos" } 1997] could serve as goodexamples of the characteristics of such a language.
One shortcoming of the language that was identified during thisresearch is the lack of constructs for conditional repeated execution. The naturalplace to insert such a language extension is in the form of a while-until-
103
ensure{ XE "while-until-ensure" } construct, in which the while-ensure{ XE"while-ensure" } sequence of behaviours is executed repeatedly until theBoolean condition in the until clause becomes true. Minor modifications wouldhave to be made to the parser{ XE "parser" }, while the End pseudo-behaviourcould be enhanced to verify the termination condition using the already existingBoolean Parser currently used only in the validation of the ensure clause{ XE"ensure clause" }.
Another possible extension of the language comes in the form of phaseswith parameters, this would allow for missions to contain sequences of stepsthat differ only in the data that they process, and the implementation, whileinvolving a number of fairly complex steps, is fundamentally straightforward.Each phase definition would have attached to it a local symbol table (in order tokeep the appropriate scope) and the names of the virtual parameters would beinserted in this table at the point of the definition of the phase. When the phaseis used (in the process of creating the graph of behaviour network nodedescriptors), the actual parameters would be bound to the virtual parametersand used as appropriate for the behaviours.
The introduction of explicit declarative stages in the missionspecification language is a very important item for future work.
One very exciting possibility opened by S* is the integration ofopportunistic behaviour into a robotic mission. Without going into the details ofwhy we consider S* appropriate for this type of task, other than to mention thepowerful mechanisms of visual attention and hierarchical internalrepresentations, it is clear that the language must be able to express the processof discovery, e.g. by expressing something like “explore the unexpectedinteresting rock that you detected in a previous step,” through the use ofvariables. One first step in this direction is the fact that behaviour envelopescontain configurable output representations, if these could be programmaticallybound to variables, this would open the door for many interesting possibilities.
104
As mentioned before, in this implementation, only daemons thatmonitor representations for changes have been provided, but through reuse ofthe BooleanExpressionParser, significantly more complex trigger conditionscan be implemented. This is not a problem for handcrafted controllers, but forlanguage-specified missions, extensions to the language might be needed toallow for programmatic control of preconditions.
A number of theoretical issues need to be addressed, probably the mostimportant of which is providing a proof for the contention that any subsumptionarchitecture can be realized using S*{ XE "S*" }, but not vice versa [Tsotsos{XE "Tsotsos" } 1997]. Also of great theoretical importance is providing themechanisms to verify a plan against timing constraints, [Tsotsos 1997]presenting a high-level description of a promising approach.
As shown in chapter 4, the behaviours, connected throughrepresentations and temporal constraints, form a directed graph. If we add toeach node a worst-case cost, proof theoretic methods can be applied in order toguarantee mission timing specifications. An initial attempt at specifying such amechanism is presented in [Tsotsos{ XE "Tsotsos" } 1997, Tsotsos 1995b].Further work in this direction is crucial to the overall acceptance of S*{ XE"S*" } as a viable alternative to traditional robot control architectures, since itwould be the only architecture that we are aware of that provides the possibilityto specify missions and provide theoretic proof that these missions satisfytemporal constraints.
As mentioned before, out of the three components of a virtual realityenvironment for robotics research, only the third, plan execution, was the focusof this research, and the first two, rover simulation and environmentvisualization were only analyzed and implemented to the level currentlyneeded, they are by no means trivial components and they deserve futureinvestigation, and collaborations with a mechanical engineering department (fora complete kinematics simulator and for research in issues such as rover-soilinteraction) and a computer graphics department (for visualization based on
105
existing data and for better simulation of local environmental conditions as wellas for a more realistic reproduction of optical system characteristics) would bebeneficial. Also, significant amounts of expertise exist within otherorganizations (most notably NASA has had a significant investment over theyears in this type of system, see [Edwards 2001], [Volpe 2001], so adding thespecific needs of S* to those systems might be an interesting avenue to pursue.
Of course, the real test of S*{ XE "S*" } will come with thedevelopment of large-scale, vision-based missions on physical robots, at whichpoint the original claims about the architecture’s scalability will be verified.
106
Appendix A – Mission Syntax
In this appendix, we provide the Yacc syntax for the mission specificationlanguage
%token START END
%token WHILE ENSURE PHASE STRING
%token <string> WHILE_ID PHASE_ID
%token STARTS WITH WITHIN DURING AFTER ENDS
%token <string> BEHAVIOURNAME REPRESENTATIONNAME
%token NUMBER SYMBOL
%token AND OR NOT EQ LT LTEQ GT GTEQ
107
%left AND OR
%type <string> while_id phase_id SYMBOL
%type <dval> NUMBER
%type <pointer> boolean_predicates
%type <pointer> individual_arg
%%
mission: mission_start phases whiles mission_end
;
phases:
| phase phases
;
whiles:
| while phases whiles
;
108
while: WHILE while_id '{' behaviours '}' ensure '(' time predicate ')'
;
while_id: WHILE_ID
;
ensure: ENSURE
;
behaviours: behaviour_statement
| behaviour_statement temp_connector behaviour_statement ';'
;
behaviour_args:
| individual_arg{}
| behaviour_args ',' individual_arg
;
109
individual_arg: REPRESENTATIONNAME
| NUMBER
| SYMBOL
;
behaviour_atom: BEHAVIOURNAME '(' behaviour_args ')'
| behaviour_list
| phase
| while
| WHILE_ID
| PHASE_ID
;
behaviour_statement: behaviour_atom ';' {}
| behaviour_statement behaviour_atom ';' {}
;
110
phase: PHASE phase_id '{' behaviour_statement '}'
;
phase_id: PHASE_ID
;
behaviour_list: '[' b_list ')'
| '(' b_list ']'
;
b_list: BEHAVIOURNAME '(' behaviour_args ')'
| b_list ',' BEHAVIOURNAME '(' behaviour_args ')'
;
temp_connector: STARTS WITH
| WITHIN
| DURING
| STARTS AFTER time
111
| ENDS WITH
| ENDS DURING
;
time:
|NUMBER
;
predicate:
| behaviour_predicates
| boolean_predicates
| behaviour_predicates AND boolean_predicates
;
behaviour_predicates: ensure_behaviourname
| not_ensure_behaviourname
| behaviour_predicates AND behaviour_predicates
;
112
boolean_predicates: boolean_predicates AND boolean_predicates
| boolean_predicates OR boolean_predicates
| '(' predicate ')'
| individual_arg EQ NUMBER
| individual_arg LT NUMBER
| individual_arg LTEQ NUMBER
| individual_arg GT NUMBER
| individual_arg GTEQ NUMBER
| individual_arg EQ individual_arg
| individual_arg LT individual_arg
| individual_arg LTEQ individual_arg
| individual_arg GT individual_arg
| individual_arg GTEQ individual_arg
;
ensure_behaviourname: BEHAVIOURNAME '(' behaviour_args ')'
;
113
not_ensure_behaviourname: NOT BEHAVIOURNAME '(' behaviour_args ')'
;
mission_start: START {}
;
mission_end: END
;
114
Appendix B – UML Diagrams
In this appendix, we provide simplified UML diagrams for relevantsubsets of the implementation.
115
Figure 20. UML - The simulated robot
116
Figure 21. UML - Behaviour envelope classes
117
Figure 22. UML - Representations used in theexamples
118
Figure 23. UML - Controllers
119
Bibliography
Albus, J.S., "The Engineering of Mind," Proceedings of the FourthInternational Conference on Simulation of Adaptive Behavior: From Animalsto Animats 4, Cape Code, MA, September 1996.
Arkin, R.,C., Behavior-Based Robotics, MIT Press, 1998
Barringer H., Fisher M., Gabbay D., Gough G., Owens R., METATEM: AFramework for programming in temporal logic. In REX Workshop on StepwiseRefinement of Distributed Systems: Models, Formalisms, Correctness (LNCSVolume 430), pp 94-129, Springer Verlag, Berlin, Germany, June 1989
Bekey, G.A., Biologycally inspired control of autonomous robots. Robotics andAutonomous Systems, 18: 21-31, 1996
120
Brooks, R.A. A Robust Layered Control System for a Mobile Robot. IEEEJournal of Robotics and Automation, 2:14-23, 1986
Davies W.H.E., Edwards P., Agent-K: An integration of AOP and KQML,King’s College Technical Report AUCS/TR9406, 1994.
De Giacomo G., Lesperance Y., Levesque H.J., Reasoning about concurrentexecution, prioritized interrupts and exogenous actions in the situation calculus.Proceedings of the Fifth International Joint Conference on ArtificialIntelligence, pp 1221-1226, Nagoya, Japan, August, 1997.
De Giacomo G., Levesque H.J., An incremental interpreter for high-levelprograms with sensing. Logical Foundations for Cognitive Agents, pp. 86-102,Springer-Verlag, Berlin, Germany, 1999
De Giacomo G., Lesperance Y., Levesque H.J., ConGolog, a concurrentprogramming language based on situation calculus, Artificial Intelligence, v.121, pp 109-169, 2000.
Dickinson, S., Stevenson, S., Amdur, E., Tsotsos, J.K., Olsson, L., IntegratingTask-Directed Planning with Reactive Object Recognition, SPIE vol. 2055,Intelligent Robots and Computer Vision XII, pp 212-224, 1993.
121
Dudek, G., Jenkin, M., Computational Principles of Mobile Robotics,Cambridge University Press, 2000.
Edwards, Laurence, et. al., VIPER: Virtual Intelligent Planetary ExplorationRover, Proceedings of the 6th International Symposium on ArtificialIntelligence and Robotics & Automation in Space: I-SAIRAS 2001, Montreal,Canada.
Fisher M., Concurrent METATEM – a language for modeling reactive systems.Lecture Notes in Computer Science, v. 694, Springer Verlag, Bonn, Germany,June 1993.
Fisher M., A survey of concurrent METATEM – the language and itsapplications. Lecture Notes in Computer Science, v. 827, pp 480-505, SpringerVerlag, Bonn, Germany, July 1994.
Hindriks K.V., de Boer F.S., van der Hoek W., Meyer J-J.Ch., A Formalembedding of AgentSpeak(L) in 3APL, Advanced Topics in ArtificialIntelligence (LNAI 1502), pp. 155-166, Springer-Verlag, 1998.
122
Hu H., Bradley M., A parallel processing architecture for sensor-based controlof intelligent mobile robots. Robotics and Autonomous Systems, 17:235-257,1996
K-Team SA, Switzerland, Khepera Robot Modules, K213 Vision Turret,http://www.k-team.com/robots/khepera/k213.html
Khatib O., “Real-time Obstacle Avoidance for Manipulators and MobileRobots,” Proceedings of the IEEE International Conference on Robotics andAutomation, St. Louis, MO, 1985, pp. 500-505
Krogh B., “A Generalized Potential Field Approach to Obstacle AvoidanceControl,” SME-RI Technical Paper MS84-484, Society of ManufacturingEngineers, Dearborn, Michigan, 1984
Latombe J-C. Robot Motion Planning, Kluver Academic Publishers, Boston,1991
Levesque H.J., Reiter R., Lesperance Y., Lin F., Scherl R.B., Golog: A logicprogramming language for dynamic domains, J. of Logic Programming.Special Issue on Reasoning Abot Action and Change, 1997
123
Maes P., “Situated Agents Can Have Goals,” Journal for Robotics andAutonomous Systems 6(3), 1990
Mataric M., “Synthetising Group Behaviours,” Proceedings of the workshop onDynamically Interacting Robots, International Joint Conference on ArtificialIntelligence (IJCAI-93), Chambery, France, August 1993, pp. 1-10
McCarthy J., Hayes P.J., Some philosophical problems from the standpoint ofartificial intelligence, Mach. Intell., v4, pp. 295-324, 1969
Nicolescu M., Mataric M.J., "Extending Behavior-Based Systems CapabilitiesUsing An Abstract Behavior Representation," Working Notes of the AAAI FallSymposium on Parallel Cognition, pages 27-34, North Falmouth, MA,November 3-5, 2000.
Nicolescu M., Mataric M.J., "A hierarchical architecture for behavior-basedrobots," Proceedings, First International Joint Conference on AutonomousAgents and Multi-Agent Systems, Bologna, ITALY, July 15-19, 2002
Rao A.S., AgentSpeak(L): BDI Agents speak out in a logical computablelanguage. In MAAMAW’96, Lecture Notes in Artificial Intelligence 1038,pp42-55, The Netherlands, 1996.
124
Rosenblat J., Payton D., “A Fine-Grained Alternative to the SubsumptionArchitecture for Mobile Robot Control,” Proceedings of the International JointConference on Neural Networks, June 1989, pp.317-323
Rosenblat J., “DAMN: A Distributed Architecture for Mobile Navigation,”Working Notes, AAAI 1995, Spring Symposium on Lessons Learned fromImplemented Software Architectures for Physical Agents, Palo Alto, CA,March 1995, pp. 167-178
Rotenstein A., Supporting Deliberation Within Behaviour-Based Systems,M.Sc. Thesis, York University, 2002.
Saffiotti A., Konolige K., Ruspini E., “A Multi-Valued Logig Approach toIntegrating Planning and Control,” Artificial Intelligence, vol. 76, no. 1-2, July1995, pp. 481-526
Shoham, Y., Agent-oriented programming. Artificial Intelligence, 60(1): 51-92,1993.
Shoham, Y., Agent-oriented programming: an overview of the framework anda summary of recent research, Knowledge Representation and ReasoningUnder Uncertainty, pp. 123-9, 1994.
125
Simmons, R., Apfelbaum, D., “A Task Description Language for RobotControl,” Proceedings of Conference on Intelligent Robotics and Systems,Vancouver Canada, October 1998.
Tam K., Lloyd J., Lesperance Y., Levesque H., Lin F., Marcu D., Reiter R.,Jenkin M., Controlling autonomous robots with Golog, . Australian JointConference on Artificial Intelligence 1997: pp. 1-12
Thomas, S.R., PLACA: an Agent Oriented Programming Language, PhDthesis, Computer Science Department, Stanfors University, Stanford, CA94305, August 1993.
Tsotsos{ XE "Tsotsos" }, J.K., "On Behaviorist Intelligence and the ScalingProblem," Artificial Intelligence 75, p 135 - 160, 1992
Tsotsos{ XE "Tsotsos" }, J.K., The S*{ XE "S*" } Proposal for ARK – InternalWorking Notes, Dept. of Computer Science, University of Toronto June 1995(Unpublished).
Tsotsos{ XE "Tsotsos" }, J.K., "Intelligent Control for Perceptually AttentiveAgents: The S*{ XE "S*" } Proposal," Technical Report RBCV-TR-96-49,University of Toronto, June 1996.
126
Tsotsos{ XE "Tsotsos" }, J.K., "Intelligent Control for Perceptually AttentiveAgents: The S*{ XE "S*" } Proposal," Robotics and Autonomous Systems 21-1, p5-21, July 1997.
Volpe R., Nesnas I., Estlin T., Mutz D., Petras R., Das H., "The CLARAtyArchitecture for Robotic Autonomy." Proceedings of the 2001 IEEE AerospaceConference, Big Sky, Montana, March 10-17, 2001
Zhang, Y. Mackworth, A. K., Constraint Nets: A semantic model for hybriddynamic systems. Theo. Computer Sci., 138:211-239,1995.