Embed Size (px)
Citation preview
Working Document:Revisions as of February 29, 2000
USING THE SIPE-2
PLANNING SYSTEM
A Manual for SIPE-2, Version 6.1
byDavid E. Wilkins
Senior Computer ScientistArtificial Intelligence Center
SRI International333 Ravenswood Ave.
Menlo Park, California 94025
Copyright c David E. WilkinsSoftware Unpublished Copyrightc SRI International
All Rights ReservedAct-Editor, Grasper-CL, PRS-CL, Cypress, GKB-Editor and SIPE-2
are Trademarks of SRI International
The writing of this manual was supported by SRI International. DARPA and Air Force Research Labo-ratory Rome supported later revisions of this manual under Contracts F30602-90-C-0086, F30602-93-C-0071, and F30602-95-C-0235.
i
Preface
This document is intended to help new users of SIPE-2 get started. Readers wishing to program in
SIPE-2 should be familiar with the representational ideas underlying the system which can be found in
the bookPractical Planning: Extending the Classical AI Planning Paradigm, D. E. Wilkins, Morgan
Kaufmann Publishing, 1988, and in the sections of this document denoted asadvanced concepts. Users
of SIPE-2 who will not program in SIPE-2 should skip these sections. This document should not be
treated as a polished or comprehensive reference. It will not be complete or even correct, as the SIPE-2
system is constantly changing. All text that appears in the typewriter font can be input to SIPE-2 exactly
as it appears.
SIPE–2’s home page, which contains pictures, descriptions of applications, and installation instruc-
tions, can be found athttp://www.ai.sri.com/˜sipe
ii
Contents
1 Overview 1
1.1 System Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 SIPE–2 as an Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Planning Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Starting and Controlling SIPE-2 8
2.1 Running SIPE-2 in the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 Profile Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Domain Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.3 Plan menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.4 Drawings Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.5 Node menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.6 Inputs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.7 Basic Grasper Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 An Example Planning Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Running SIPE-2 without the GUI .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 Solving Problems 26
3.1 Naming Plans and Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.2 Following the Planning Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Movie Mode and Customizing Search . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Automatic Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1 Solving as an Agent and Programmatically . . . . . . . . . . . . . . . . . . . 32
3.5 Controlling the Solution Process .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.1 Instantiating Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.2 The Advisable Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
iii
3.6 Interactive Solving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.1 An Initial Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6.2 Interactive Search Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.6.3 Interactive Search Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6.4 Window Layouts with Choice Pane. . . . . . . . . . . . . . . . . . . . . . . 41
3.7 Modifying Plans and Worlds: What-if Analyses . . . . . . . . . . . . . . . . . . . . . 42
3.8 Intermingling Planning and Execution . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.9 Overview of Automatic Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 Drawing Plans and Other Structures 47
4.1 The Drawing Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Drawing SIPE-2 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1 Plans and Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.2 Plan Decompositions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.3 Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.4 Initial World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 The Birds-Eye–View Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 The Node Sizes Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6 Customizing Drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.6.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.6.2 Text Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 Colors in Drawings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.8 Customizing Node Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.9 Miscellaneous Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5 Printing Data Structures 63
5.1 Printing in the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Printing without the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Printing Internal SIPE-2 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6 The SIPE-2 Web Server 70
6.1 Running the SIPE-2 Web server .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2 Known Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3 Example Web Server session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
iv
7 Plan Execution and Replanning 74
7.1 Overview of Execution and Replanning . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.2 Execution and Replanning Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.3 Executing a Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.4 Replanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.5 Intermingling Planning and Execution . . . . . . . . . . . . . . . . . . . . . . . . . . 82
8 Interacting with Other Systems 83
8.1 The Act-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.1.1 Translation From ACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.1.2 ACT Translation Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
8.1.3 Translation to ACT with Dictionary Creation . . . . . . . . . . . . . . . . . . 86
8.2 The GKB-Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.2.1 Creating and editing a Sort Hierarchy in GKB .. . . . . . . . . . . . . . . . . 87
8.2.2 Browsing a plan decomposition drawing. . . . . . . . . . . . . . . . . . . . . 88
8.2.3 Running the GKB Web Server. . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.2.4 Running the GKB-Editor directly. . . . . . . . . . . . . . . . . . . . . . . . 88
8.2.5 Programming Aids for the GKB-Editor . . . . . . . . . . . . . . . . . . . . . 89
8.3 Cypress Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
9 Dictionaries and Completion 91
9.1 Dictionary and Verification Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.2 Creating a Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.3 Using a Dictionary in SIPE-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
9.4 Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
10 Why Doesn’t SIPE-2 Work (Faster)? 98
10.1 Recovering from Stuck States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
10.2 Debugging . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
10.3 Analyzing and Improving Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 102
11 Inputting the Domain 104
11.1 General Syntax, Punctuation, and Comments . . . . . . . . . . . . . . . . . . . . . . 106
11.2 Properties and Comments on Plans and Operators . . . . . . . . . . . . . . . . . . . . 107
11.3 Defining Primitive Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
11.4 The SIPE-2 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
11.5 Variables and Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
v
12 Initial World State 111
12.1 Sort Hierarchy Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
12.2 Inputting the Sort Hierarchy . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
12.3 Inputting Initial World Predicates .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
13 Operators 118
13.1 Slots on Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
13.2 Operator Arguments and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
13.3 Variable Descriptions and Variable Pointers . . . . . . . . . . . . . . . . . . . . . . . 125
14 Plots and Problems 127
14.1 Defining Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
14.2 Plot Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
14.3 Generating Parallel Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
14.4 Syntax for Plots and Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
15 Customizing the Planner 135
15.1 Controlling Planning Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
15.1.1 Search Cutoffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
15.1.2 Ordering links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
15.1.3 User Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
15.1.4 Critics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
15.2 Procedural Attachment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
15.3 Efficiency Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
15.4 Plan objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
15.5 Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
16 Reasoning about Partially Ordered Actions 147
16.1 Efficiently Handling Partially Ordered Actions . . . . . . . . . . . . . . . . . . . . . . 148
16.2 Considering All Possible Orderings . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
16.3 External-Condition Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
17 Using Deductive Rules 151
17.1 Existential and Universal Quantifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
17.2 Init-Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
17.3 Efficiency Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
17.4 Pitfalls — Important! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
vi
18 Numerical Reasoning 156
18.1 Numerical Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
18.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
18.3 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
18.3.1 Function Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
18.3.2 Current-value and Previous-value Constraints . . . . . . . . . . . . . . . . . . 161
18.4 Predicates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.5 Accumulating Numerical Quantities. . . . . . . . . . . . . . . . . . . . . . . . . . . 162
18.5.1 Consumable Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
18.5.2 Recursive Accumulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
18.6 Temporal Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
18.6.1 Initializing temporal reasoning. . . . . . . . . . . . . . . . . . . . . . . . . . 167
18.6.2 Temporal reasoning with Tachyon. . . . . . . . . . . . . . . . . . . . . . . . 168
18.6.3 Temporal reasoning with Duration as Uncertainty . . . . . . . . . . . . . . . . 170
A SIPE-2 Input for the Blocks World 175
B SIPE-2 Input for the Missionaries and Cannibals Problem 180
C SIPE-2 Input for the Mobile Robot World 186
C.1 Robot Ontology and Predicates . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
D SIPE-2 Input Syntax 189
D.1 General Syntax, Comments, Punctuation, etc. . . . . . . . . . . . . . . . . . . . . . . 189
D.2 Domain, Predicate, and Problem Definitions . . . . . . . . . . . . . . . . . . . . . . . 190
D.3 Operator Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
D.4 Sort Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
D.5 Local Variable Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
E Correspondence of SIPE-2 and ACT Syntax 196
F SIPE-2 Functions and Source Code 199
F.1 Top-Level Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
F.1.1 Generating Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
F.1.2 Loading Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
F.1.3 Modifying Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
F.1.4 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
F.2 Sort Hierarchy API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
vii
F.3 Slots on Plan and Plot Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
F.4 Slots on Predicate Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
F.5 Slots on Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
F.6 Functions for Plan Objects and Contexts . . . . . . . . . . . . . . . . . . . . . . . . . 209
F.7 Functions for Traversing Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
F.8 Functions for Critics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
F.9 Functions for Truth Criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
F.10 Functions for Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
F.11 Functions for Time Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
F.12 Index to SIPE-2 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
G Implementing Parallel Links 219
H CLIM Peculiarities and Bugs 221
H.1 Stuck States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
H.2 Parameter Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
H.3 Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
H.4 Miscellaneous Bugs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
viii
List of Figures
1.1 SIPE-2’s View of the Planning Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 SIPE-2 Modules and Flow of Control. . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 SIPE-2 Search Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 SIPE-2’s Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 GUI Command Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Military Plan Highlighting Resource: Fennario Port . .. . . . . . . . . . . . . . . . . 16
2.4 Brewery Plan Highlighting Actions that Consume Resources . . . . . . . . . . . . . . 17
3.1 Menu for Trace in Profile Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Menu for Invoking Automatic Problem Solving . . . . . . . . . . . . . . . . . . . . . 31
3.3 Main Menu for Interactive Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Check Constraints Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Menu for Interactive Search Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Menu for Choosing Goal to Solve with Mouse. . . . . . . . . . . . . . . . . . . . . . 40
3.7 GUI with Choice Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.8 Algorithm for Producing a New Planning Level. . . . . . . . . . . . . . . . . . . . . 45
4.1 Profile for Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 New View Menu for Labeling and Filtering a Plan for Drawing. . . . . . . . . . . . . 49
4.3 Drawing of Predicates in Robot World. . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4 Drawing of Classes in Sort Hierarchy in Robot World .. . . . . . . . . . . . . . . . . 54
4.5 Birds-eye View of a Large Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1 Menu for Printing a Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Display Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Menu for Printing Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4 Displaying a Variable during Robot Planning. . . . . . . . . . . . . . . . . . . . . . 69
7.1 Control and Data Flow in the Replanner . . . . . . . . . . . . . . . . . . . . . . . . . 75
ix
7.2 Profile for Execution and Replanning . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.3 Menu for Choosing Node to Execute. . . . . . . . . . . . . . . . . . . . . . . . . . . 80
8.1 Profile for Act Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
9.1 Dictionary Profile Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
9.2 Entering a Predicate in the Oil-Spill Domain . . . . . . . . . . . . . . . . . . . . . . . 96
11.1 SIPE-2 Syntax for Properties and Comments in Block-World Operator . . . . . . . . . 107
12.1 Representing the Initial World State. . . . . . . . . . . . . . . . . . . . . . . . . . . 112
13.1 SIPE-2 Input for Puton1 Block-World Operator. . . . . . . . . . . . . . . . . . . . . 119
13.2 SIPE-2 Input for Block-World Deductive Rules. . . . . . . . . . . . . . . . . . . . . 119
14.1 SIPE-2 Input for a Conditional Plot. . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
14.2 SIPE-2 Input for Two Problems . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
14.3 Cleartop Operator Using Generate-Goals . . . . . . . . . . . . . . . . . . . . . . . . . 132
15.1 Menu for Planning Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
15.2 Menu for Setting Efficiency Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
15.3 Important Slots in a Plan object and their Values . . . . . . . . . . . . . . . . . . . . . 144
17.1 SIPE Deductive Rules With and Without Universals . .. . . . . . . . . . . . . . . . . 153
18.1 Menu for Numerical Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
18.2 Block-World Operator Using Consumable Resources . . . . . . . . . . . . . . . . . . 163
18.3 Operator that Accumulates Boom at an Oil Spill . . . . . . . . . . . . . . . . . . . . . 165
18.4 Classes for Variable Names Specifying Temporal Constraints . . . . . . . . . . . . . . 167
18.5 Sipe Operator with Tachyon Temporal Constraints . . .. . . . . . . . . . . . . . . . . 171
18.6 Sipe Operator using Duration-as-Uncertainty . . . . . . . . . . . . . . . . . . . . . . 172
C.1 Map of Robot World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
x
Chapter 1
Overview
This document introduces SRI International’s SIPE–2 (System for Interactive Planning and Execution)
planning system. The software runs on Symbolics Lisp Machines and Sun workstations with either
Allegro CL 4.3 and CLIM 2.0 or later, or Lucid Lisp 4.1 and CLIM 1.1.1 Some interface features
described in this manual work only in the CLIM environment. Restrictions on the CLIM version are
explicitly noted.
SIPE–2’s home page, which contains several pictures, descriptions of applications, and installation
instructions, can be found athttp://www.ai.sri.com/˜sipe
This document contains sufficient information about SIPE–2 for a user to use a SIPE–2 application
already developed for a particular problem domain. However, a SIPE–2 programmer, i.e., someone
attempting to model a new domain in SIPE–2, should be familiar with the representational ideas un-
derlying the system. In particular, the programmer should be familiar with the material in the book
Practical Planning: Extending the Classical AI Planning Paradigm[8], and the paperCan AI planners
solve practical problems?[9]. Certain sections of this document labeled asadvanced conceptscan be
skipped by a user; they are intended for the programmer and assume knowledge of the above references.
Chapters of interest to the user appear first in this document; Chapter 11 and all chapters following it
are intended for the programmer, as are some portions of earlier chapters.
This document includes several useful appendices. These include description of functions, an index
to the source code, a formal specification of the input language, and commented SIPE–2 input for four
different problem domains: the blocks world, the blocks world with fuel requirements, the missionaries
and cannibals problem, and the planning of actions for an indoor mobile robot. Graphical knowledge
editors exist to input most SIPE–2 structures. However, many users input domain knowledge using text
files, so the formal specification of the syntax in standard Backus-Naur Form (BNF) is spread throughout
this document. Appendix D contains the full description in one place and describes how to read the BNF.
1It would not be difficult to port the systems to other lisps that support Common Lisp and CLIM.
1
1.1 System Description
Reasoning about actions is a core problem in artificial intelligence (AI), and the SRI International AI
Center has been conducting research into planning and problem-solving systems for the past three
decades. The most advanced of SRI’s planning systems, SIPE–22, provides a formalism for describing
actions and utilizes the knowledge encoded in this formalism, together with its heuristics for handling
the combinatorics of the problem, to generate plans to achieve given goals in diverse problem domains.
The generated plans have causal information included in them so that the system can modify these plans
in response to unanticipated events during plan execution. Unlike expert systems, SIPE–2 is capable of
generating a novel sequence of actions that responds precisely to the situation at hand.
SIPE–2 is a hierarchical, domain-independent, partial-order AI planning system. Unlike most AI
planning research, heuristic adequacy (efficiency) has been one of the primary goals in the design.
Because this technology is generic and domain-independent, it has the potential to affect a large variety
of problems in fields as diverse as manufacturing, construction, and the military. SIPE–2 has been
applied to planning the actions of a mobile robot, planning the movement of aircraft on a carrier deck,
travel planning, construction tasks, the problem of producing products from raw materials on process
lines under production and resource constraints, oil-spill response, and transportation planning for Joint
Forces course-of-action development. To enable comparisons with other planners, SIPE–2 has also
been applied to several toy problems, including the blocks world with extensions, the tower-of-hanoi
problem, and the missionaries and cannibals problem.
SIPE–2 provides a powerful formalism for representing domains and automatically generating plans
in them. However, many types of domains cannot be represented adequately in SIPE–2, including do-
mains involving uncertainty or relaxation of conflicting constraints. The operator description language
was designed to be easy to understand (to enable graceful interaction) while being more powerful than
those found in previous domain-independent planners. Constraints, resources, and causal rules all con-
tribute to the power of the representation by supporting conditional effects, increased efficiency and
expressibility, and improved capabilities for dealing with the parallel-interaction problem. Alternative
plans can be explored concurrently using the system’s context mechanism. SIPE–2 provides flexibility
in specifying the rationale behind a plan, as well as execution monitoring and replanning capabilities.
The user is able to specify unexpected occurrences as a plan is being executed. SIPE–2 can then iden-
tify all the problems caused by these occurrences in the remaining plan and attempt to replan to correct
them.
To enable significant user involvement in the plan development process, SIPE–2 provides a rich
advice-taking facility. With this facility, users can direct the planning process in a powerful and general
2The research underlying SIPE was initially supported by the Air Force Office of Scientific Research. SRI International,the Australian AI Institute, and the Advanced Research Projects Agency have supported further development ofSIPE–2.
2
manner through the provision of high-level guidance that influences the nature of the solutions gener-
ated. Advice consists of task-specific properties of both the desired solution and the problem-solving
process to be used for a particular problem. As such, advice is an adjunct to the domain knowledge that
underlies a given planning application. Details of the advice-processing capabilities within SIPE–2 can
be found in a companion document [5].
1.2 SIPE–2 as an Agent
This manual describes the stand-alone use of SIPE–2 as a planning system. SIPE–2 has also been used
as an agent in SRI’s Multiagent Planning Architecture (MPA), communicating with other agents via
KQML messages.
MPA is intended to serve as an architecture for large, sophisticated planning problems that require
the coordinated efforts of diverse, geographically distributed human and computer experts. It facilitates
incorporation of new tools and capabilities as they become available, and allows the planning system
to capitalize on the benefits of distributed computing architectures for efficiency and robustness. MPA
provides protocols to support the sharing of knowledge and capabilities among agents involved in coop-
erative planning and problem solving.
MPA is a separate software system that can be obtained from SRI. MPA includes two SIPE–2-based
agents that responds to various messages that can be sent to SIPE–2 to invoke its planning capabili-
ties. MPA provides an agent wrapper in LISP that supports asynchronous interagent communication,
including functions for making, sending and replying to messages that log and trace the message ex-
change. There are also functions for starting and killing agents, and for starting and stopping tracing.
This wrapper can easily be employed by any agent running in a LISP image.
SRI further extended the KQML system used within MPA with SRI’s system-management code.
This provides version control and a patch facility (for LISP agents), which we find to be of crucial
importance in maintaining working demonstrations. We have uncovered a few bugs that have been fixed
by patches in the SRI version of KQML. In SRI’s software distribution, KQML is automatically loaded
as a subsystem by the MPA system.
Two functions that can be used to generate plans as an agent are described in Section 3.4.1. Working
documents describing MPA can be found athttp://www.ai.sri.com/˜wilkins/mpa
1.3 Basic Concepts
The inputs and outputs of SIPE–2 are depicted in Figure 1.1. While the inputs to the planner attempt to
model the “real world,” current AI techniques cannot handle the full complexity of our everyday world
3
State ofthe World
Actions OneMight Take Problems
Operators
Goals
Planner
ActionStructure
Execution Monitorand Replanner
Actions
Beliefs,resources,constraints
Figure 1.1: SIPE-2’s View of the Planning Problem
and generally it is an abstraction of the real world that is represented. The vertical arrows in the figure
indicate the relationship of representation, by which entities in the world are encoded internally in the
planning system. The planner’s output will be correct only to the extent that the representation correctly
reflects the real environment. The output is a sequence ofprimitiveactions to be carried out by whatever
agents are accepting instructions from the planner.
SIPE–2 takes as input a description of the initial state, a description of a set of actions, a problem
descriptor, and a set of rules describing the domain. The initial state consists of asort hierarchy, a
world model, and a set of deductive rules. The sort hierarchy represents invariant properties of perpetual
objects, describes the classes to which an object belongs, and allows for inheritance of properties. The
world model is a set of predicates which hold over objects in the sort hierarchy. Anoperator is the
system’s representation of actions or abstractions of actions that may be performed in the domain.
The system automatically, or under interactive control, generates plans (i.e., sequences of known
actions) to solve the given problem and supports replanning after unexpected occurrences during execu-
tion. The planner produces a tree of alternative plans. These are accessed through a plan object stored
for each alternative. Plan objects are necessarily created only when plans are named (all final plans
are named). Thus, a plan generated automatically will have one one plan object, for the final plan. A
4
plan generated interactively will have a plan object for each plan level, with all but the last representing
partial plans. (There is always an “in-progress” plan object used when a plan is being generated, it is
copied whenever a plan is named.)
Each plan object specifies, among other things, the plan’s name, action network, action-network
name andcontext. Plan objects and contexts are described in detail in Chapter 15). A symbol that is a
plan name will evaluate to the corresponding plan object. The action network points to the task network
for the plan, and the symbol that is an action-network name will evaluate to the first node of the action
network. Note that the printed representations of plan objects use the action network name, not the plan
name.3
The planner searches for a solution using a simple search strategy until an acceptable plan has been
produced. Alternatively, the user may guide the planning process interactively. Implementing other
search strategies such as best-first would not be a difficult extension of the system.
It may be easiest to learn to use the planner by studying the blocks world example in Appendix A,
or the mobile robot example in Appendix C. It may be useful to run the planner on the blocks example
while reading this document. This can be done by selecting theInput command under the Domain
menu, and loading the initial default file (sipe:input;blocks.sipe). Appendix F describeseach slot that
can be on a plan, operator, or predicate node.
1.4 Planning Modules
Figure 1.2 shows how the various parts of the system fit together. It depicts a conceptual division of the
planning system into different modules for expository purposes. The arrows indicate that one module
depends on (i.e., calls functions from) another module. The top-level search algorithm determines how
often to apply plan critics (algorithms that discover problems that must be fixed), when to check for
resource conflicts, when to stop planning and to start execution, and when to call the interpreter to
elaborate the plan by applying an operator to one of the goals in the plan. (The interpreter interprets
the plan language in which operators are written.) Thetruth criterion determines whether a formula
is true at a particular point in time and is called by all the modules except the input/output modules.
The truth criterion assumes that all deduced effects have been inserted in the plan before it is called.
Thus the interpreter invokes the causal theory when expanding a plan so that the truth criterion need not
consider making these deductions. The execution monitor also uses the causal theory to deduce effects
of unexpected occurrences. The replanner and the critics both use replanning actions to modify existing
plans.
3Functions in this manual with an argument named “plan” take a plan object as the value of that argument, while thosenamed “context” expect a list of CPPs, and those named “plan-con” can handle either.
5
SIPE-2 Top Levelautomatic or interactive
ResourceReasoning
&Allocations
Plan Critics &Solvers
ExecutionMonitoring &Replanning
Interpreter
Truth Criterion and Unification
ReplanningActions
DeductiveCausal Theory
Figure 1.2: SIPE-2 Modules and Flow of Control
The plan critics are responsible for finding problems in the plans produced and for correcting them.
Primarily, this involves checking whether the global constraint network is satisfiable, finding resource
conflicts, checking which goals are already true, and finding problematic interactions between unordered
actions. The critics make use of the replanning actions that may modify plans, sometimes removing
subplans in order to make better plans.
SIPE–2 allows customization of the problem solving process and encourages users to develop their
own search control algorithms. Figure 1.3 shows the basic template that search control algorithms must
fit. Various customizations described in Chapters 3 and 15 make it easy to modify this basic template. By
default, the critics are applied at the end ofeach planning level. They can be applied less frequently by
setting their frequency in planning levels or more frequently by using the interactive search. Chapter 16
describes how the critics and truth criterion interact to enable efficient planning.
When planning is finished and the user orders execution, the search algorithm relinquishes control
to the execution monitor. This module accepts descriptions of arbitrary unexpected occurrences. It
then determines how these occurrences affect the plan being executed, possibly modifying the plan by
removing certain subplans and inserting certain goals. When the resulting plan contains unsolved goals,
the execution monitor again calls the search algorithm to expand this plan. The execution monitor makes
use of theplan rationalethat has been encoded in the plan. (The rationale for an action in a plan is why
the action is in the plan.) This is needed for determining how long a condition must be maintained, what
changes in the world cause problems in the plan, and what the relationship is among actions at different
6
SIPE-2 Top Levelautomatic , interactive, or controller agent
Resourceallocation and
scheduling
Plan Critics &Solvers
Select a goal
Modify plan toavoid conflicts
Select anoperator
Apply operator togoal
Deduceconsequences
PLAN EXPANSION PHASE:continues until controllerdecides to critique plan
PLAN CRITIQUE PHASE:continues until all conflictscorrected or deferred by controller
FINAL PLAN :-all goals expanded-all conflicts corrected
Figure 1.3: SIPE-2 Search Control
levels of abstraction.
7
Chapter 2
Starting and Controlling SIPE-2
First, log on to the computer, enter the appropriate window system, start running a COMMON LISP that
includes CLOS and CLIM, and evaluate(sri:run-system :sipe) . Run-system loads the system
if the system is not already loaded. To load SIPE–2 without running it, call(sri:load-system
:sipe) . Loading SIPE–2 loads Grasper,1 and the Act-Editor as subsystems.
Grasper [1] supports the graphical interface, and the Act-Editor [11] supports graphical editing of
operators. The GKB-Editor (Generic Knowledge Base Editor) supports graphical editing of the sort
hierarchy and isnot loaded when SIPE–2 is loaded. If the user desires to use the GKB-Editor, the
system can be loaded by evaluating(load-gkb) after loading SIPE–2. Each of these systems has its
own reference manual, obtainable from SRI.
Note: all L ISP symbols in the manual are in the sipe package unless otherwise noted. Thus,
(load-gkb) is equivalent to(sipe::load-gkb) .
Grasper can support more than one application at the same time. The user can switch between
Grasper, SIPE–2, and the Act-Editor by selecting them from the Application Menu (see the following
section). See Appendix H for details of system management, version control, and the patch facility.
Note that evaluating(sri:exe-history) prints version information about all loaded systems. The
variable*sipe-release* also saves version information about SIPE–2.
This chapter describes the graphical user interface (GUI) of SIPE–2, and then describes an example
planning session.
1Grasper will be used throughout this manual to refer to the most recent Grasper systems available. Currently, these areGrasper II on Symbolics machines and Grasper-CL on Sun workstations.
8
Figure 2.1: SIPE-2’s Graphical User Interface
2.1 Running SIPE-2 in the GUI
The GUI contains several window panes (see Figure 2.1). The vertical pane along the left side of the
screen is contains the command menus for controlling SIPE–2. The first command,Application, invokes
the Application menu, which allows the user to choose among the Grasper-based systems that have been
loaded.
The large pane to the right of the command pane is the graph pane, which provides graphical display
capabilities. The pane under the graph pane is the GUI Lisp listener, whichaccepts keyboard input,
evaluates Lisp expressions, parses commands, and displays textual output. Below the GUI Lisp listener
are documentation lines, which provide information about the current file/graph and explain the actions
of various mouse clicks whenever the mouse is over a mouse-sensitive item (such as a command).
TheLayoutcommand in the Profile menu (described later) can be used to change the relative size
9
and placement of these panes. Additional layouts that can be selected include pull-down command
menus and a choice pane for making choices during interactive planning sessions (see Section 3.6.4).
In Figure 2.1, the system is displaying an operator from the missionaries and cannibals domain in
Appendix B.
The graph pane is scrollable, so the window can be moved to the left, right, up, or down over the
displayed plan. The displayed nodes are mouse-sensitive so that clicking on them causes their contents
to be shown in their entirety in the GUI Lisp-listener or in a pop-up window. Appendix H describes
some peculiarities in the CLIM (Sun) implementation.
Figure 2.2: GUI Command Menus
Figure 2.2 shows the command menus used by the GUI. The top six commands in each menu are
“nouns” that select the appropriate command menus (“verbs”) for that noun. The Profile menu activates
commands for setting defaults that allow the user to customize the behavior of SIPE–2. The Domain
menu activates commands that apply to the problem domain as a whole, e.g., inputting and inspecting
a domain. The Plan menu activates commands that apply to a specific plan, including executing a plan
and solving a problem to produce a plan. The Drawings menu activates commands that draw various
SIPE–2 structures. Objects that can be drawn include plans, operators, the sort hierarchy, the initial
10
world model, and problems. Finally, the Node menu activates commands that apply to specific nodes in
the currently drawn plan.
Although not illustrated in the above figures, SIPE–2 now supports an additional item in its noun
menu, namely Advice. The associated Advice commands enable users to create, edit, modify, and trace
advice for the planning process. Details of the advice menu can be found elsewhere [5].
Typically, a planning session would begin by clicking onDomain to display the Domain menu,
clicking on Reset(if another domain is loaded), and then clicking onInput for as many files as are
needed to define all the structures mentioned in Chapter 11.2 By clicking onTracein the Profile menu,
the user can set parameters that control how much output is produced during planning. A problem can
then be solved by entering the Plan menu and clicking on eitherInteractiveor Automatic. The Drawings
menu can be used to draw the plan produced or other structures such as the sort hierarchy or operators.
After returning to the PLAN menu,Executecan be clicked to execute the plan.
In this section, we briefly describe each command. Some commands are described in detail, but
detailed explanations of others are given in the chapters that discuss the relevant topics.
2.1.1 Profile Menu
The commands in the Profile menu are used to set up defaults for how the planner plans, how the GUI
draws and prints objects, and what the planner prints while planning.3 Each command is described in
the chapter describing the functionality controlled by the command, as follows:
Trace— controls printing during planning, Chapter 3
Planning— controls behavior during planning, Chapter 15Execution— controls behavior during execution, Chapter 7.3Efficiency— controls behavior affecting efficiency, Chapter 15Numerical— controls behavior affecting numericals, Chapter 18
I-Search— controls behavior affecting interactive planning, Chapter 3Search Space— controls how many plans to find and how to search, Chapter 3
Printing — controls how structures are printed, Chapter 5Drawing— controls what is drawn on each node, Chapter 4
Node Sizes— sets sizes of drawn nodes, Chapter 4Node Colors— sets the colors for drawing each type of node, Section 4.7Node Shapes— sets fonts and other parameters for drawing nodes, Chapter 4
Completion— controls completion of names being input, Chapter 9
2Generally, there is one master file that loads all necessary files. In Lucid and Allegro Lisp, the master file must useeval-load instead ofload to load other files, as described in Appendix H.
3Customizations are often placed in input files by setting the appropriate variables in the Lisp fileglobals-customize ,as described in Section 15.
11
Dictionary— associates dictionaries with the current domain, Chapter 9ACT — controls translations to the ACT formalism, Chapter 8
Layout— changes layout of window panes in the GUI, Section 3.6.4Colors— sets colors of window panes in the GUI, Section 4.7Birds Eye— controls use of birds-eye window, Section 4.4
2.1.2 Domain Menu
The commands in the Domain menu are used to reset the system, load a new domain, and list and print
various structures.Resetrestores SIPE–2 to its initial state, destroying all structures that have been
created since the last reset.Inputprompts for a filename and loads the specified file. The user may load
as many input files as desired without resetting SIPE–2. Modify provides three choices for modifying
the domain:
� Interactively add predicates to a specified world.
� Edit operators using the Act-Editor.
� Edit sort hierarchy using the GKB-Editor.
Clear Plansremoves all pointers to plans and problems so that the space can be reclaimed for
garbage collection. If the variable*domain-problem-file* is set for your domain, the file defin-
ing problems will be reloaded.Find gives four choices for finding operators and predicates:
� Find predicates matching a template
� Find predicates using an object
� Find operators concluding a predicate
� Find operators achieving a predicate.
Both theList andPrint commands have several forms, depending on what is being listed or printed:
operators, problems, plans, plan decompositions, nodes, worlds, objects, and contexts.Objectsrefers
to classes and instances in the sort hierarchy. TheList commands list the names of all such structures
known to SIPE–2, with the exception of nodes. There are generally too many nodes for a listing of them
all to be helpful. Instead,List Nodesprints a list of all the plan nodes in the particular plan selected
by the user. An additional command,List Files Inputprints all the files that have been input using the
Input command. ThePrint commands print a textual description of particular structures in the GUI
12
Lisp listener or a pop-up window. This window and the form of the printed description are set with the
Printing command in the Profile menu, as described in Chapter 5.
The last two commands translate operators to the ACT formalism [10], thus allowing the Act-Editor
to be used to graphically edit operators. The ACT formalism also allows knowledge to be shared with
other systems that support the ACT formalism, e.g., SRI’s Procedural Reasoning System (PRS-CL).
The-> ACTcommand translates selected operators, creating Acts in the current Grasper graph. The->
ACT all command converts all operators and allows several options, including automatic creation of a
dictionary for the operators (see Chapter 8).
2.1.3 Plan menu
The commands in the Plan menu are used to manipulate, execute, and generate plans, and are described
in more detail in Chapter 3. Completely new plans are created by solving problems in the domain;
several commands invoke the SIPE–2 problem-solving algorithms:
Automatic— invokes automatic problem solvingInteractive— solves a selected problem under interactive controlInteractive-1— expands a selected problem under interactive control for one planning levelContinue— continues interactively solving the current planContinue-1— continues interactively expanding the current plan for one planning levelMovie-Mode— solves a problem while generating plan drawings at each planning level
Three commands create new plans or plan names by modifying existing plans.Abstractmakes
named plans out of all abstract partial plans generated while solving a particular problem.Regroup
makes a new copy of a given plan and adds ordering links to this copy according to an algorithm for
regrouping plan actions.Renamerenames the current plan and its drawing.
The following commands do not generate new plans:
Execute— invokes the execution monitor on the current plan with graphics (see Chapter 7)Execute-any— invokes the execution monitor on a selected plan
Print — same as thePrint Plancommand of the Domain menuPrint options— prints the plan with many options for controlling printingDestroy— removes a plan from the list of recognized plansOutput— saves the entire plan to a fileInput— inputs a plan from a file
Add Goal— adds a goal to the current planDelete Goal— deletes a goal from the current planAdd Facts— adds predicates to the world and analyzes the current plan for problems
-> ACT — translates the current plan to the ACT formalism
13
ACT Options— allows translation of several plans with several options-> PRS— translates the current plan to ACT and loads it into PRS-CL.4
The commandsRenameandDestroyalso perform their respective actions on any existing drawing
with the same name.Destroysimply hides the plan from the GUI. Internal data structures are actually
destroyed only when the domain is reset, so a “destroyed” plan can still beaccessed as long as a pointer
to it remains. Translating a plan to the ACT formalism allows users to graphically edit the plan.
2.1.4 Drawings Menu
The Drawings menu can be used to draw system structures graphically and manipulate these drawings.
TheDraw command has several forms: operator graph, operator, problem, plan, plan decomposition,
world, and objects. As described in Section 4.2, each of these commands creates a drawing of a certain
type. For example, Figure 2.1 shows the drawing of an operator. The settings of theDrawingcommand
in the Profile menu, which is described further in Chapter 4, determine the form of the drawing. (As in
the Domain menu,Objectsrefers to classes and instances in the sort hierarchy.)
Select, Destroy, andDestroy-multipleperform the named actions on existing drawings. As described
in Chapter 4,New Viewpermits the user to redraw an already drawn plan in a different manner, including
changing the sizes of nodes, the types of nodes drawn, and the slots drawn with each node.Magnify
can be used to expand or shrink any drawing (imperfectly).Renameallows drawings to be renamed. In
the case of plans and problems, the underlying SIPE–2 structure will also be renamed if it has the same
name as the drawing.
Most of the remaining commands are borrowed from Grasper and manipulate drawings and collec-
tions of drawings. These commands are documented in detail in the Grasper reference manual [2]. A
Graspergraph is essentially a collection of drawings that can be associated with a filename and saved
on disk. There are five commands that manipulate graphs:selectchooses a graph;creategenerates a
new graph with a new filename;destroyremoves an existing graph;input reads in a graph from a file;
andoutputwrites a graph to a file. The underlying structures cannot be written to a file with these
commands.5 Thus, any drawings that are input from a file of drawings can exist only in the exact form
in which they were output. For instance,New Viewcannot be used on such a drawing to relabel it or to
change the types of nodes that were drawn. The remaining commands are summarized below:
Browse— allows browsing of the current drawingRedraw— redraws the graphics paneReparse— reparses the underlying SIPE–2 structure into a new drawing
4This command is active only when SRI’s Cypress system is loaded.5TheOutputcommand in the Plan menu can save plans to a file, the GKB-Editor can save the sort hierarchy to a file, and
the Act-Editor can save operators to a file.
14
Backup— saves (internally, not to disk) a copy of the current displayed drawingRevert— reverts to the most recently backed-up copy of the drawingRescale— rescales the current drawingHardcopy— draws the current drawing to a hardcopy output device.
TheBrowsecommand draws only a few nodes of the current drawing and the user can then expand
and contract the drawing with mouse clicks. Browsing is useful for large plans, which otherwise might
have initial nodes too spread out for easy visualization. TheRedrawcommand is useful if the screen
contains garbage.Reparseis used when a SIPE–2 structure has changed since it was last drawn. For
example, a plan may be drawn before the plan critics are invoked. Clicking onReparseafter the plan
critics have been applied will show the plan as modified by the critics.
2.1.5 Node menu
The commands in the Node menu are used to find and modify nodes, to find resources and predicates
at nodes, and to view, by highlighting nodes, various properties of a plan. The highlighting and finding
options can be helpful when analyzing large plans, which can be difficult to interpret. The modification
options are useful for customizing the appearance of a drawing — the user can move nodes with the
mouse to make the drawing look exactly as desired.
Print prints a textual description of a specific node to the GUI Lisp listener or a pop-up window.
The window and the form of the printed description are set with thePrinting command in the Profile
menu, as described in Chapter 5. Printing a node can also be invoked by clicking left on a node in
most drawings.Print-Ancestorsprints a textual description of all the higher-level ancestors of a specific
node to the GUI Lisp listener. The finding and modification options are borrowed from Grasper and
summarized below:
Find-Node— finds a node in the drawing and highlights it in the graphics paneFind-Edge— finds an edge in the drawing and highlights it in the graphics pane
Reshape— modifies the appearance of a node or edgeReshape-group— modifies the appearance of a group of nodes or edgesMove— drags a node to a new locationMove-group— drags a group of nodes to a new location
Align — aligns nodes horizontally or verticallyAlign-mode— selects mode to use for theAlign command.
TheCompletioncommand in the Profile menu can be used to choose how theFind-Nodecommand
queries for a node. The default is to select from a menu for a small number of choices, and to type a
name with completion when the number of choices is large.
15
There are six commands that highlight nodes to aid analysis of the plan; three address temporal
aspects and three address objects and resources. Using the commandsPredecessors, Successors, and
Parallel, one can highlight, respectively, all the successors of a node, all the predecessors of a node, or
all the nodes that are unordered with respect to a node. In domains with hundreds of temporal links, this
capability can prove invaluable. The commandsResource, Argument, andPredicateallow the user to
highlight all nodes that mention a certain object or resource, or all nodes that make certain predicates
true.
Figure 2.3: Military Plan Highlighting Resource: Fennario Port
Two examples from SIPE–2 applications show the utility of these features. Figure 2.3 shows a
plan for a military operation. The GUI highlights all the nodes that mention Fennario Port, effectively
showing the schedule for that port. Similarly, highlighting all the nodes that are unordered with respect
to a certain node could show all actions in the current phase of the operation. Figure 2.4 shows a plan for
the daily production-line schedule in a large brewery. By clicking on thePredicatecommand and then
requesting all the actions that have the predicate named CONSUME in their effects, the user highlights
all the actions that consume resources (in this case, the only resource is beer).
16
Figure 2.4: Brewery Plan Highlighting Actions that Consume Resources
2.1.6 Inputs
This sections provides hints for using the CLIM interface. Most of the mouse-based selection operations
are activated by left-clicking on some appropriate item. For this reason, the phrase ‘click on an item’
is used throughout this guide to mean ‘click using the left mouse button’. When either middle- or
right-clicks are required, they will be mentioned explicitly.
Some commands immediately put up a menu of choices or a window asking for confirmation. For
some windows, such as confirmation windows, you must hold the mouse button down after clicking on
the command and drag over to the desired choice before releasing the button. A quick click will result in
no action being taken — the confirmation window may briefly flash on the screen, but it will have been
exited without confirmation for the action. For some commands, such as many choice menus, there are
two options. Again, you can hold the mouse button down after clicking on the command and drag over
the list of choices that appear. Alternatively, a very quick, sharp click will cause the menu to appear
and remain for later selection. A more lingering click with have no effect — the menu will flash on the
screen but be exited without a selected choice.
17
When inputing to CLIM, Emacs-like control characters often provide editing capabilities during
type-in (including control-Y to yank text). (Assuming you have employed SRI’sclim.Xdefaults
file as specified in the installation instructions.) For example, such editing capabilities are available
while typing to the interactor pane and while typing expressions in menus. In the interactor pane, meta-
control-Y will recall the last input, and meta-Y can then be used repeatedly to yank previous inputs. On
Sun workstations, theDel key and not theBackspace key must be used for deletions.
Certain commands employ a type of interactive menu called a Parameter Choice (PC) Menu. This
menu displays the current settings of a number of program parameters, which the user can then alter.
Here we describe how these menus handle input in CLIM 2.6 Some parameters have a small fixed
number of possible values; these can be selected from a menu with the current value displayed next to a
“radio box” indicating there is a menu of choices.
Other parameters can take on a value that the user provides; for example, this situation arises with
several profile commands. There are two different input forms, one with a CLIM box around the entry,
and one without. They differ significantly in how input is terminated.
Without a CLIM box, left-click on the current value to delete it and enter an alternative, and middle-
click on the value and a cursor will appear and Emacs-style editing commands can be used to modify
the entry. Inputmustbe terminated by the Return key; hitting Return immediately will simply reinsert
the original entry (even if it has disappeared after a left click). When all parameters have the desired
values, the user should click onSave Changes (or equivalent) at the bottom of the menu. Clicking
onAbort restores the original values.
With a CLIM box, either a left-click or a middle-click will activate the box for input and allow
Emacs-style modification of the existing entry. In this box, control-K does not kill the rest of the line,
but meta-control-DEL will. If other edits are to be made, inputmust notbe terminated by the Return
key; hitting Return causes the menu to exit as ifSave Changes had been clicked.
A second type of pop-up window is used for entering a single input (as is the case when a name is
required for a new Act). These windows act like PC menu inputs without a CLIM box. That is, left-click
replaces, middle-click modifies, and Return exits.
Two conventions are observed throughout our CLIM interfaces. First, whenever a pop-up menu is
present on the screen, pressing control-Z with the mouse pointer inside the menu aborts the execution
of the current command and returns to the top level, or, for some commands in the Component menu
that loop selecting components, to the selection loop.7 Control-Z also returns to the top level if pressed
when keyboard input is expected.
6In CLIM 1, things are different, but fairly obvious. For example, “radio-box” choice are all displayed and can be clickedto select.
7In CLIM 1, because of a bug in CLIM, the user sometimes must next press some key (e.g., Rubout or any letter) with themouse inside the GUI, or commands in the command pane will not be mouse sensitive.
18
Second, at times when the user is prompted for keyboard input, a default response is printed be-
tween square brackets or quotation marks. The user can select the default by pressing either Return
or control-meta-Y followed by Return. Control-meta-Y can also be used to yank defaults in pop-up
menus. Defaults often appear in pop-up menus, but when the user clicks on a default, it disappears.
Typing control-meta-Y yanks the default back into the buffer.
2.1.7 Basic Grasper Concepts
As noted above, the SIPE–2 is layered on top of a graphical editing tool called Grasper-CL. To under-
stand the workings of SIPE–2, a few Grasper concepts are useful (for more information about Grasper,
consult its manual [2]).
Grasper-CL [1, 2] is a COMMON LISP system developed at SRI for displaying and manipulat-
ing graphs. Grasper-CL supports interactive graph editing and provides a foundation for constructing
graphical user interfaces (GUIs) for application programs whose inputs or results can be presented as a
graph. SIPE–2 constitutes one such application, while the Act-Editor and PRS-CL are others.
The primitive building blocks in Grasper-CL arenodesandedges. Nodes and edges are displayed
as a combination of anicon and alabel. The label is simply a string to be printed. The icon is a shape
used in displaying the node, such as a rectangle or an ellipse. Icons can be invisible; in which case, only
the label is displayed. SIPE–2’s Profile menu allows users to customize colors and other properties of
node labels and icons.
Nodes and edges are grouped into a data structure called aspace. In SIPE–2, each drawing (whether
a plan, operator, problem, or other structure) is in its own Grasper space.
In turn, spaces are grouped into a collection called agraph. Each graph is stored as a separate
file (with extension .graph). The filename is displayed in the status line of the GUI. Graphs can be
manipulated using commands in the Drawings menu, e.g., graphs can be saved to disk using theOutput
command. It is important to remember that the termgraph is never used to refer to an actual drawing
of a graph (e.g., the drawing of a plan is a directed, acyclic graph).Graphalways refers to a group of
spaces associated with a file.
The user always works in a particulargraph, the current graph. The filename of the current graph is
displayed in the status line of the GUI. Most commands apply to the current space in the current graph,
although some of the commands in the Drawings menu look at all the spaces in the current graph. A
space can be selected using theSelectcommand in the Drawings menu. If the user switches graphs, the
system will no longer know about drawings in the previous graph.
If a SIPE–2 plan is highly parallel or contains many sequential actions, the virtual window panned
over in the graphics pane may be too short or too narrow, respectively. The size of the virtual window
can be changed using the WINDOW noun menu in Grasper. The system can become less efficient with
a large virtual window.
19
Domain File name
Blocks World sipe:input;blocks.sipeMissionaries and Cannibals sipe:input;cannibals.sipe
Robot Planning sipe:input;robot;demo.sipeTower-Of-Hanoi sipe:input;tower-of-hanoi.sipeTravel domain sipe:input;travel;travel.sipe
Blocks World with fuel sipe:input;blocks-fuel.sipe
Table 2.1: Domain Files
2.2 An Example Planning Session
This section describes how a user can interact with SIPE–2 to generate and draw plans. It is assumed
that SIPE–2 is already loaded and running. Whenever the mouse is over a command in the GUI, the
documentation for that command appears near the bottom of the GUI.
Initially, SIPE–2 hassipe.graph as its current graph — this graph is used as a scratch graph, so
should not be saved to disk. To support saving your drawings to disk, we begin by creating a new graph.
� Click on theDrawingscommand in the upper part of the command menu; the Drawings com-mands appear in the command pane.
� Click on thecreatecommand underGRAPH.
� In response to the prompt, enter the name of the file in which the graph should later be saved (suchas"/homedir/examples.graph" ). If desired, the prompt can be edited with Emacs-likecommands.
� The next prompt asks for the name of a new space within that graph, typeFoo.
SIPE–2 now has your graph as the current graph, and Foo as the current space. First it is necessary
to load the definition of a planning domain. Table 2.1 shows some of the files of domain definitions that
are distributed with SIPE–2, and are useful as a tutorial.
� Click on theDomaincommand in the upper part of the command menu; the Domain commandsappear in the command pane.
� Click on the Input command, which prompts for a file name. Entersipe:input;blocks.sipe , which is the initial default, and press Return.
� Try various commands underList andPrint. For example, click onList OperatorsandList objects,then click on any windows that appear to dismiss them.
� Click on Print operator, and hold the mouse button down. Release the button after dragging themouse to thePuton1choice.
20
� Click on any windows that appeared to dismiss them.
Now we will generate some plans in the blocks world. The initial world state is that of the Sussman
Anomaly. It is assumed the user will exit all PC menus by clicking the appropriate box at the bottom
(e.g.,Do It).
� Click on thePlancommand in the upper part of the command menu; the Plan commands appearin the command pane.
� Click on theAutomaticcommand, which brings up a PC menu. ClickDo It to solve the firstproblem.
� After planning, a menu will appear. From the menu of choices for “Draw Plan Graphically”choose “Use-Default”. ClickDo It and a drawing of the plan will appear.
� Click on theMovie Modecommand, which asks for a problem to be solved. Select “Two Conj”from the menu — this is the standard Sussman Anomaly.
� SIPE–2 will draw partial plans and flash nodes as it plans. It will create five drawings and sleepafter each drawing for a few seconds.
Now we will generate a plan interactively, allowing more user control of the planning process.
� Click on theProfilecommand.
� Click on theI-Searchcommand (for Interactive Search), which brings up a PC menu.
� For the “Display option at each plan level” option, select “Draw” from the menu, then clickDo It.Other options allow user control of planning, but the blocks world has few choices. Later, in themissionaries and cannibals problem, the “User chooses operator at each node” option is a goodchoice for interactive planning.
� Click on thePlancommand.
� Click on theInteractive-1command, which asks for a problem to be solved. Select “Red Blue”from the menu — the problem is to get some blue block on another blue block and to also getsome red block on another red block. This expands the plan one planning level and stops.
� Continuously click on theContinue-1command to expand the plan until completion. Two suchclicks will be required for this problem.
Now we will use the GUI to further inspect the plans. Click left on any node in a drawing to see the
node displayed with more detail in a pop-up window.
� Click on theDrawingscommand in the upper part of the command menu; the Drawing commandsappear in the command pane.
21
� Click on theNew Viewcommand, which brings up a PC menu. Click on the box for “FilterPhantoms”, then clickDo It. You will see a plan drawing that includes both the action nodes andthe phantom nodes.
� The drawing is probably now too large for the window. You can scroll with the scroll bars.
� To make more nodes fit in the window, click on theNew Viewcommand again, click on the boxfor “Args labeling”, and then move to the top and select “Small” from the menu of sizes.
� Click Do It and the new drawing will have smaller nodes.
� Click on some of the nodes in the drawing to see more information about them.
� Click on any windows that appeared to dismiss them.
Most New-View options other than size remain in effect for future plan drawings. Now we will draw
items in the planning domain other than plans.
� UnderDraw, click on theObjectscommand, which brings up a PC menu.
� Click Do It and a drawing of the sort hierarchy will appear.
� Again, you can click on nodes to see more information about them. Click on “A” to see itsproperties.
� Click on any windows that appeared to dismiss them.
� UnderDraw, click on theWorld command, which brings up a PC menu. Click on the “Displayall predicates” option, andDo It. A drawing of the predicates in the initial world state will appear.
Now we will further inspect the plan for the red-blue problem.
� Click on theSelectcommand and choose the drawing for the red-blue plan. You can drag themouse, or get the menu to stay with a sharp click on the command.
� Click on theNodecommand in the upper part of the command menu; the Node commands appearin the command pane.
� Click on thePredecessorscommand.
� Click on the node that put R2 on R1 to see its predecessors highlighted, or right click to abort.
� Right click to end the highlighting and return to the GUI.
� Click on theArgumentcommand.
� Enter R1 for the object to find, and the actions with R1 as an argument will be highlighted.
� Right click to end the highlighting and return to the GUI.
22
� Click on thePrint-Ancestorscommand.
� Click on any node, or right click to abort.
� Right click to end the highlighting and return to the GUI.
Now, we will load the missionaries and cannibals domain.
� Click on theDomaincommand.
� Click on theResetcommand, and continue holding the mouse down until it is over the confirma-tion that appears. Click on the second confirmation.
� Click on theInputcommand. Entersipe:input;cannibals.sipe using Emacs-like com-mands (e.g., type meta-Del twice and then “cannibals”) and press Return.
We will now generate all possible solutions to the missionaries and cannibals problem.
� Click on theProfilecommand.
� Click on theSearch Spacecommand, which brings up a PC menu.
� For the “Search space for multiple plans” option, select “Gensym-names” from the menu, thenclick Do It.
� Click on thePlancommand.
� Click on theAutomaticcommand, which brings up a PC menu. ClickDo It to solve the firstproblem. SIPE–2 will search the entire space and find four plans.
� Click on theDrawingscommand.
� Click theDraw Plancommand, and select one of the four plans, then clickDo It.
� Click theDraw Plan Decompositioncommand, then clickDo It, and you will see how the planwas decomposed from the most abstract level down to the final plan.
Now we will have the user control planning in the missionaries and cannibals problem. See if you
can solve the problem!
� Click on theProfilecommand.
� Click on theSearch Spacecommand, which brings up a PC menu.
� For the “Search space for multiple plans” option, select “No” from the menu, then clickDo It.
� Click on theI-Searchcommand.
23
� Select the “User chooses operator at each node” option and the “Check preconditions before userchooses operator” option (both are in the top group), then clickDo It. The latter option removes allinapplicable operators before asking the user to choose. In some domains this can be inefficient,but here it is fast and makes it much easier to find a plan.
� Click on Layoutand select the last choice, “Top Menu with Lower Interactor and Choice”. Thecommand menus will now be pull-down menus, and user choices will appear in the pane at thelower right.
� Click on thePlanbutton at the top.
� Click on theInteractivecommand, which asks for a problem to be solved — simply clickDo It.
� The interactive planning menu presents many choices. Continuously click on thePLAN NEWLEVELchoice to expand the plan.
� Whenever a choice appears in the choice pane (lower right). Select the operator you wish toapply by clicking on it and then clickingSelectat the bottom of the choice pane. You can alsoclick Describeto see the operator drawn before you make a choice. If planning continues withoutoffering you a choice, it means that only one operator was applicable.
� At any point, in the interactive search menu, you can selectQUIT to stop planning (e.g., to usethe GUI before continuing) orFinish planning automaticallyto let SIPE–2 finish what you havestarted.
� To continue after quitting, click thePlanbutton at the top, then theContinuecommand.
If you make the right choices, SIPE–2 should find a final plan. If not, you can interactively direct
backtracking by invoking theInteractivecommand and selecting the “Backtrack in last plan” option.
TheFinish planning automaticallyoption may become more appealing.
To stop planning, selectExit or Kill Lisp Processfrom the Application menu.
2.3 Running SIPE-2 without the GUI
SIPE–2 can also be run, without graphics, from any Lisp listener on Symbolics, or from the window
running the main Lisp process on Suns. Because of the small size of the GUI Lisp Listener, it is often
advisable to develop and debug applications by running SIPE–2 in such a window. In CLIM, the CLIM
root window must be initialized, so first call(run-sipe) and then exit. SIPE–2 can be controlled
in this case from the top-level menu, which can be obtained by calling the functions(sipe) or (s) .
This menu contains most of the important commands from the Profile, Domain, and Plan menus of the
GUI. A brief summary of the top-level menu follows:
24
Efficiency Hacks— sets a variety of parameters affecting efficiencyPlanning Profile— sets a variety of parameters controlling SIPE–2Trace Profile— sets flags for controlling what SIPE–2 prints
Load File— loads an input file (or any other file)Reset Sipe— restores SIPE–2 to its initial state
Execute— executes an existing planInteractive Solve— solves a defined problem under user controlAutomatic Solve— uses the automatic search to solve a defined problem
Display— pops up a command menu for printing objects (see Section 5.2)List Plans— lists all plan names in use
Quit — returns to whatever you were doing beforeLisp— enters a Lisp break pointHelp— prints a summary of all options.
Typically, a planning session begins by clicking onReset Sipe, and then clicking onLoad File for
as many files as are needed to define all the structures mentioned in Chapter 11. By clicking onTrace,
the user can set parameters that control the amount of output produced while SIPE–2 is planning. A
problem can then be solved by clicking on eitherInteractive Solveor Automatic Solve. Displaycan be
used to inspect the planning results andExecutecan be clicked to execute the plan.
25
Chapter 3
Solving Problems
Once a domain has been input, the Plan menu can be used to solve one of the defined problems. This
chapter describes the commands in the Plan menu relevant to problem solving. SIPE–2 provides auto-
matic plan generation as well as a flexible and powerful interactive planner, which allows the user to be
an integral part of the planning process at many different levels of detail. This chapter also describes
how to graphically follow the generation of a plan and discusses some advanced topics regarding the
modification of goals and problems, what-if analyses, and the intermingling of planning and execution.
The commands grouped with theSolvecommand in the Plan menu invoke the SIPE–2 problem-
solving algorithms and generate new plans by solving problems. Two additional commands,Abstract
and Regroup, create new plans by modifying existing plans. Most of these commands can also be
invoked without the GUI, as described in Section 2.3.
Clicking on Abstractmakes named plans out of all abstract partial plans generated while solving
a particular problem. This feature is useful after the automatic search has solved a problem and the
user wishes to look at the plan as it developed level by level. Clicking onRegroupmakes a copy of
the current plan and adds further ordering links to the copy. Hopefully, this regrouping makes the plan
easier to understand [9]. The regrouping algorithm first groups all nodes that could be executed first,
then all nodes that could be executed first after that group, and so forth. How to allow the user to specify
additional orderings of the least-committed plan remains an interesting research issue.
Clicking on eitherAutomatic, Interactive, Interactive-1or Movie-Modegenerates a solution for a
problem that has not been previously solved. The commandsContinueandContinue-1continue prob-
lem solving on a partial plan. TheAutomaticandMovie-Modecommands attempt to find a solution
without interaction with the user. The former invokes the automatic search algorithm, while the latter
invokes the interactive search algorithm but always selects the default choice at any choice point. The
other commands all invoke the interactive search algorithm, which permits the user to watch and, when
desired, to guide and/or control the planning process. Interactive solving facilitates debugging an appli-
26
cations, allows a human expert to guide SIPE–2, and allows the system to address larger problems that
may initially be beyond the capabilities of fully automatic planning techniques.
While SIPE–2 does not continually monitor the world and react to changes during the planning
process, it can accept changes in the world at the beginning of each planning level and modify the plan
to react to them. This option can be selected with thePlanningcommand in the Profile menu and makes
use of the replanning capabilities described in Chapter 7.
3.1 Naming Plans and Contexts
SIPE–2 uses an automatic naming scheme for generated plans to support multiple alternative plans. This
scheme distinguishes between partial plans and final plans. Any plan is named by prepending “PLAN-”
to the action-network name. Final plans will additionally have “-Px” appended to the end of that name,
where “x” is an integer. Backtracking may generate random names for partial plans. The search leaves
a list of plan objects (for all final plans found) in the variable*current-plans* . SIPE–2 clears
*current-plans* each time a search is initiated and sets the variable whenever a plan is generated.
SIPE–2’s search algorithms have been built on basic mechanisms that facilitate the ability of users
to encode their own search strategies. Acontextis the most important of these mechanisms. A context
is stored in the plan object and tells the planner which alternatives are part of the current plan. In this
chapter, it is necessary to know only that contexts exist. Programmers wishing to interactively explore
alternative plans and contexts are referred to the more detailed description of plan objects and contexts
in Chapter 15.
3.2 Following the Planning Process
Clicking on any node in a drawing displays a window that contains most of the information about that
node. This feature is useful for debugging and user interaction. For example, SIPE–2 records the reason
each failed operator did not apply. This reason is either the argument whose constraints failed to match
or the precondition predicate that was not true. These descriptions can be viewed by clicking on a node
that has been expanded.
Users often invoke theTracecommand in the Profile menu before planning. It controls how much
the planner prints about what it is doing. There is a tradeoff between efficiency (printing takes time) and
knowing what the planner is doing. If all tracing flags are turned off, the planner prints nothing until it
either succeeds or fails. There are various levels of tracing — from printing a notice when each planning
level is entered, to printing a notice about every significant action, to printing extremely detailed notices
for debugging.
27
Figure 3.1: Menu for Trace in Profile Menu
Figure 3.1 shows the menu that pops up after the user clicksTrace in the Profile menu. When an
application is debugged and only the final plan is desired, trace flags will often be turned off. When
developing or demonstrating an application, the trace flags are essential. The menu is divided into three
parts. The high-level tracing options are the most important.
“Notices for following the search” prints a few lines about alternatives and critics aftereach planning
level. Tracing domain definition is useful for finding syntax errors as the system prints notices foreach
object, operator, and class as it is defined. The next two high-level options are for following critics. A
notice can be printed every time a critic is applied, or every time an ordering link is added by a critic.
There are two options for inhibiting printing that is done by default. Some trace options print the whole
plan at the end of each planning level. When a plan becomes large, this option may be undesirable and
can be inhibited. The second inhibit option stops the printing of a one-line notice when starting a new
planning level. This option is generally inhibited only when it is desired that SIPE–2 print absolutely
nothing.
The second part of the trace profile traces operator expansion. Printing one line for each expansion
is useful for monitoring the progress of planning. Similarly, printing one line for instantiations is useful
28
when the user is concerned about how planning variables get instantiated. The third option can be
used to follow the planning system during demonstrations — it prints the expansion produced for each
operator application and prints the plan at the end of each planning level. For a large plan, this generally
takes too long.
Advanced Concepts:The rest of this section describes tracing options that only programmers are
likely to use.
There are now three levels of tracing for following the backtracking behavior of the search, con-
trolled by 3 boolean variables. The first two variables below are options in the trace profile, while the
third is an option in the extremely low-level tracing menu.
debug3 [Variable]
If value isT (default isNIL ), the planner traces backtracking at a high level, printing one line per
backtrack and search cutoff. Set with “Notices for following the search” in the trace profile.
debug-search-detailed [Variable]
If value isT (default isNIL ), the planner traces backtracking at a more detailed level, but without
listing the nodes it might expand at various points. Set with “Detailed notices for following the search”
in the trace profile.
debug-search-detailed-nodes [Variable]
If value isT (default isNIL ), the planner traces backtracking at its most detailed level, listing the open
nodes at each backtrack.
The last part of the trace profile, low-level tracing, should be used only by programmers for de-
bugging. Most of the options are self-explanatory, and should be used selectively as large amounts of
tracing information will be printed. One option is to bring up a menu of extremely low-level tracing
options, which should be used only after SIPE–2 has planned to the point where a problem is occurring.
For example, when the planner is about to apply an operator to a specific node would be the time to
trace the details of matching in order to discover why the operator is or is not being applied. These trace
options print too much output to be used throughout the planning process.
3.3 Movie Mode and Customizing Search
TheMovie-Modecommand provides a “movie” of the planning process. At each level, the plan is drawn,
nodes are flashed as they are expanded, and ordering links are flashed as they are added. Movie mode
handles backtracking and searching for multiple plans. SIPE–2 either sleeps or allows a confirming
click after each drawing, with an option to suspend and use the GUI to examine the plan.
29
Both the interactive search and automatic search are described in their own sections. Customizations
that apply to movie mode and to both interactive and automatic searches are described in this section.
Several commands in the Profile menu —Trace, I-Search, Search Space, Planning, andEfficiency
— can be used to customize the planner before commencing planning. ThePlanningandEfficiency
commands are only for programmers and are described in the chapter on advanced customizations
(Chapter 15). The following variables, interactively set with theI-SearchandSearch Spacecommands,
can be set in an input file to customize problem solving. However, most of these values can be given as
arguments when problem solving is invoked (see next section), so are only needed to establish global
defaults for the domain.
sleep-time-for-movie-mode [Variable]
The value is an integer specifying the number of seconds to sleep after drawing a plan in movie mode.
It is used only when the value ofauto-interactive-search is :sleep .
fast-interactive-search [Variable]
This variable specifies whether and how to present the new plan at each planning level. Legal values
are :draw , :print , :use-menu , and:neither , corresponding to drawing the plan, printing the
plan, querying the user with a menu, and continuing planning, respectively.
multiple-answers [Variable]
If non-nil, the system searches for multiple plans instead of quitting after finding one plan. Legal values
areT, NIL , and:gensym-names . A value ofT means the user is asked for a name for each plan.
number-of-answers [Variable]
If multiple-answers is non-nil, this variable indicates the number of plans to be found. Legal
values are an integer orNIL . NIL causes all plans to be found by exhaustively searching the search
space.
*default-depth-limit* [Variable]
This is an integer specifying the default depth limit used by the automatic search.
*time-limit* [Variable]
This is the default time limit in seconds (see functionsolve for details). The default value,NIL ,
indicates no time limit.
3.4 Automatic Solving
TheAutomaticcommand of the Plan menu is used to invoke automatic problem solving. The search
algorithm expands a plan level by level until no plan can be produced (failure), one or more complete
30
plans are produced (success), or a depth limit is reached. Upon either failure or reaching the depth limit,
the search algorithm backtracks to the most recent choice of operators and tries a different operator.
Eventually, either a plan is found or all operator choices are exhausted.
Figure 3.2: Menu for Invoking Automatic Problem Solving
Figure 3.2 shows the menu obtained by clicking onAutomatic. The first few choices are arguments
to the search algorithm, while the remaining choices provide easy access to certain Profile-menu com-
mands. Generally, the only item that needs to be selected is the problem to be solved — simply select
one of the known problems displayed in the menu. A depth limit (an integer) can also be chosen; the
user must be sure to pick one large enough to allow the problem solution to be found. Finally, an advice
scenario can be chosen (this choice will not appear if no advice scenarios are defined). Advice scenarios
are defined with theAdvisable Planner, see Section 3.5.2.
Three options are presented for controlling the exploration of the search space. The first provides
the option of quitting after one plan is found or of backtracking to find several different plans for the
same problem. When finding multiple plans, the system provides an option for automatically generating
names for them (normally, the system asks the user to name each plan). The second search-space option
allows the search to be stopped after a certain number of plans are found. If the value isNIL , the entire
search space will be explored when multiple plans are requested. The third option allows planning
”automatically” down to a given level, and then stopping with a partial plan. When a partial plan
is produced, it can then be expanded interactively with the commandsContinueor Continue-1(after
possibly setting tracing, etc.).
31
When the user exits this menu, the search algorithm is invoked and the user is given a chance to
name the finished plan for each solution that is found (unless the option for automatic name generation
has been selected). A more detailed description of the search algorithm is given in Section 3.9.
3.4.1 Solving as an Agent and Programmatically
Advanced concepts:This section is for programmers and should be skipped by those not intending to
use this capability.
This section describes functions that can be used to support agent-based plan generation, and to
invoke planning programmatically. Agents often refer to a plan by name in messages. Functions that
find the plan object for a given plan or action-network name are described in Appendix F.6. The most
commonly used such function isfind-plan-for-plan-name .
The functionsolve-act takes a task expressed as an Act and generates a plan (or plans) for
that problem. The functiongenerate-plan takes the name of a SIPE–2 problem and generates a
plan (or plans) for it. (It is called bysolve-act after the Act has been translated to a problem.)
Solve-problem is similar, solving a named plan, but has more options and different defaults. The
former has defaults more suited for use in a server, while the latter is more suited for local use within
SIPE–2. Both functions convert the problem to a partial plan and callsolve .
The functionsolve takes a SIPE–2 partial plan and automatically generates one or more final
plans for it — it is used for replanning or to further expand a partial plan. Finally, the function
initialize-problem is used to convert a named problem to a partial plan, suitable forsolve .
This translation involves copying the problem, renaming it, doing deductions, checking phantoms, and
creating a plan object.
These functions are documented in detail in Appendix F.1.1. These functions can be used inside an
agent’s message handler, which may write the generated plan to a plan server. Most of these plan gener-
ation functions take the same keyword arguments. The most important keywords are briefly described
here to show the range of available options. Most of the keyword arguments default to the values of
global variables described in Section 3.3.
Facts is a list of predicates that will be added to the initial world before planning.
Multiple-plans determines whether to search for multiple plans and how to name them. If
NIL , only one plan is found. If:gensym-names , multiple plans are found, and a name foreach plan
is generated (planning continues without user interaction). IfT, multiple plans are found, and the user is
queried after each plan for a plan name, whether to display the plan, and whether to continue searching.
Number-plans is an integer orNIL and is only used ifmultiple-plans is non-nil. The
system will stop when this many plans have been found. If the value isNIL , the entire search space will
be explored when multiple plans are requested.
32
Partial-plan-at-level is an integer orNIL . If integer, the search will stop planning after
that many levels, naming the partial plan and setting it up for interactive planning using the commands
ContinueandContinue-1.
Depth-limit is an integer – the search will not expand past this many expansion levels.
Time-limit is a real number in seconds. If more than this many seconds have elapsed, the search
will not start a new level, a backtrack, or start applying a set of operators to a node. The system will
continue applying critics or trying operators on the current node. Thus, the time limit is too coarse-
grained for fractions of a second, and cannot guarantee returning within a certain time.
3.5 Controlling the Solution Process
Advanced concepts:This section is for programmers and should be skipped by those not intending to
use this capability.
Programmers implementing a domain may wish to provide additional ways to control the solution
process that make use of domain-specific knowledge. SIPE–2 provides three techniques for accom-
plishing such control: (1) giving an operator prioritization function tosolve , (2) providing a variable
instantiation function, and (3) using theAdvisable Planner. These options affect both automatic and
interactive planning. Advanced programmers may want to implement their own search control algo-
rithms.
Option 1 provides little power and is superceeded by Option 3 (so is not documented except in the
code). However, it is simple to use if it serves the desired purpose. The latter options are described
below, with Option 3 providing by far the most power and control.
3.5.1 Instantiating Variables
Option 2 is described by the following variable.
*instantiation-function* [Variable]This value is the name of a function to call for instantiating variables.
This function should take 3 arguments: a varptr (see Section 13.3) for a variable, a list of varptrs forinstances that meet the constraints on the variable, and a plan object. It should return a list of varptrs,possibly after removing items from the input list. New objects can be added to the return value, but thisimplies acceptance of any constraint violations incurred by choosing such an object. (Remember, theplanner already provided this function with a list of all objects that satisfied constraints.)
This function is called both during critic application on a final plan (when all planning variableswill be instantiated), and during expansion of an operator with an Instantiate slot (see Chapter 13). It
33
is called both during automatic planning and when the user interactively choose instantiations. In thelatter case, the user sees only those choices returned by this function.
The planner will use the returned value as follows:
� If the value is of length 1, the variable will be instantiated to this varptr.
� If the value is the same list that was passed in as the second argument, the planner proceedsnormally.
� If the value is NIL, the plan critic or expansion will fail.
� If the value is of length greater than 1, the variable will be limited to these varptrs only on thiscall to critics/expansion. No permanent constraint limiting the variable to this set of values willbe posted. Thus, the result of this returned value will have no effect unless either the user ischoosing instantiations interactively, or constraints on other variables force an instantiationduringthis critic/expansion.
3.5.2 The Advisable Planner
SIPE–2 incorporates the Advisable Planner system [4]. The Advisable Planner enables users to direct
the planning process in a more powerful and general manner, through the provision of high-level guid-
ance that influences the nature of the solutions generated. Advice consists of task-specific properties of
both the desired solution and the problem-solving process to be used for a particular problem. Advice
is an adjunct to the domain knowledge that underlies a given planning application.
One form of advice provided by the Advisable Planner is strategic advice, which can be used to
control the search for a solution in SIPE–2. Strategic advice expresses recommendations on how goals
and actions are to be accomplished, in terms of both specific approaches to pursue and entities to employ.
Strategic advice comes in two forms:roleandmethod. Role advice constrains the use of domain entities
in solving tasks, while method advice constrains the type of approach used. Strategic advice designates
not only properties of the resultant plan, but also the underlying justifications for that solution.
The URLhttp://www.ai.sri.com/˜myers/projects/ap.html provides information
about the Advisable Planner, including a manual for its use.
3.6 Interactive Solving
SIPE–2 provides a flexible and powerful interactive planner. The user may interact with the planning
process at many different levels of detail, and use the GUI to follow plan generation and view informa-
tion relevant to planning decisions.
The Interactivecommand of the Plan menu is used to invoke interactive problem solving. It first
asks the user to choose a problem to solve, or to choose from the set of already constructed partial plans.
34
It then asks whether to draw the selected problem, and finally uses its search algorithm to solve the
problem as directed by the user through a series of menus. Menus continue to be displayed until a final
plan is produced or all possibilities are exhausted. The user may quit solving the problem at any time
and use theContinuecommand to resume solving later. TheInteractive-1andContinue-1commands
are similar, but the system speeds up interaction by not displaying certain menus and returns to the
top-level of the GUI after expanding the plan one level. TheContinue-1command can then be used
repeatedly until the final plan is produced.
Under interactive control, the user can control
� When and how resources are allocated
� Which operators are applied to which nodes
� Which goal to solve next (when goals are unordered)
� Which goals to delay solving
� Whether to backtrack or continue searching the current plan
� Which plan level to use for backtracking
� Naming of alternative plans
� Display of structures relevant to planning decisions
� Which object to use as instantiations of planning variables
� The method for resolving conflicts found by the plan critics.
At any time, the user can instruct SIPE–2 to continue planning automatically, thus allowing the user
to interact at high levels of abstraction only, while the planner fills out the details. All the above options
can all be selected independently, permitting great flexibility in the human-computer interaction. The
current implementation expands plans in a left-to-right expansion order, one level at a time, although
the system design does not require it. When several goals are unordered with respect to each other, the
user can choose which goal to expand, or can delay expanding the remainder of the goals. By choosing
such delays, the user can expand one part of the plan in as much detail as desired without expanding
other parts of the plan.
When the user interactively controls exploration of the search space, SIPE–2 does not guarantee
completeness without duplication if the plans contain parallel actions (it does for linear plans). Heuris-
tics have been added that eliminate much of the duplication when the user is in control and appear
not to sacrifice completeness. These heuristics also allow SIPE–2 to recognize and eliminate duplicate
solutions.
35
3.6.1 An Initial Example
A simple interactive planning session might proceed as follows: Options for human-computer interac-
tion can be chosen by using theI-Searchcommand in the Profile menu, or by selecting theSet Options
command in the top-level interactive search menu. The options for drawing the plan at each level and
having the user select the operators are chosen. When the interactive search is first invoked, SIPE–2
asks for a problem to solve, asks whether to draw the problem, and then displays the top-level interac-
tive search menu, which then pops up at the beginning of each planning level. The user selectsPlan
New Leveleach time the menu appears, and clicks on the desired operator each time a menu pops up for
choosing operators. During operator selection, the node being expanded is highlighted and the user can
draw operators before making a final selection. At the end of each planning level, the plan is drawn. At
some point, SIPE–2 will print a notice that a solution has been found, andQuit can then be clicked in
the next display of the interactive search menu.
The user can try an interactive planning session with either the blocks world, the missionaries and
cannibals problem, or the mobile robot world. The domain input for these worlds is included in ap-
pendices of this manual and is distributed with SIPE–2 in the filessipe:input;blocks.sipe,
sipe:input;cannibals.sipe, andsipe:input;robot;demo.sipe.
The following sections describe the interactive search menu and the options menu in greater detail.
3.6.2 Interactive Search Menu
At the beginning of each planning level, the interactive-search menu shown in Figure 3.3 appears. Click-
ing on eitherInteractive-1or Continue-1initiates a fast version of the interactive search that skips this
menu. In the fast version, the search exits after each planning level and the user clicksContinue-1to ini-
tiate the next planning level. Thus the fast search consists of repeatedly clicking onContinue-1without
ever seeing the interactive-search menu or the options menu.
After each planning level, before the plan critics are applied, the plan is drawn or a menu for naming
and drawing the plan is presented to the user (as specified by the options). The interactive-search menu
appears after the plan critics are applied and before the next planning level commences. To redraw the
plan after modifications by the plan critics, the user may clickRedraw Current Planin the interactive-
search menu.1 For example, the user must choose to redraw the plan after Tachyon is called to process
temporal constraints in order to see the new time windows. TheDraw Plancommand can be used to
draw a different plan or to draw the current plan with different drawing options.
The first item in the interactive-search menu lists the expandable plans for which the system can
continue planning. Anexpandable planis a plan object for a partial plan, i.e., a plan that is ready to
1This command has been added since Figure 3.3 was saved. Unfortunately, CLIM menu-choose windows cannot be savedas postscript files.
36
Figure 3.3: Main Menu for Interactive Search
expand to a new planning level. In the interactive search, alternative plans are selected by their plan
name, which can be used to access the plan object. The other commands in the first group are self-
explanatory;Set Optionsinvokes theI-Searchcommand of the Profile menu.
The second group of commands control the search algorithm itself, and most display a menu that
asks the user which partial plan to operate on. If no alternative plans have yet been produced, SIPE–2
begins expanding the current plan. These commands are summarized below:
Retry Old Choices— backtracks to last unexplored choice and tries itPlan New Level— expands a new levelApply Critics— applies all critics immediatelyCheck Constraints— invokes resource allocation and constraint satisfactionFinish Planning Automatically— invokes the automatic search on a selected partial plan.
Figure 3.4: Check Constraints Menu
Two items require explanation.Retry Old Choicesinvokes backtracking and highlights the nodes
that are backtracking choices, after allowing the user to choose the plan level for backtracking. Clicking
on Check Constraintsdisplays the menu in Figure 3.4. It gives the user three options for controlling
constraint satisfaction and, thus, resource allocation. The first option is self-explanatory. If the second
option is selected, SIPE–2 lets the user make choices whenever it has to instantiate a variable and more
than one instantiation is possible. The last option immediately applies the constraint-satisfaction critic
to a selected partial plan.
Most of the remaining items of the interactive search menu are self-explanatory:
37
QUIT — exits interactive problem solving and returns to the top level of the GUISuspend to Display— allows full use of the GUI while suspending problem solvingLisp— enters a Lisp break point immediately.
Only Suspend to Displayrequires more explanation. This command creates an additional SIPE–2
GUI, while the original GUI is suspended, waiting for the new GUI to exit. Planning will be continued
when the new GUI is exited (by clicking onExit in the Applications menu, see Appendix H).
Advanced Concepts:The expandable plans are kept on the variable*expandable-plans* ,
and backtracking choices for the current problem are kept on the variablechoices . These are both
set toNIL whenever a new problem is started. However, their old values are pushed onto the vari-
ablesold-plan-levels andold-interactive-choices in case the programmer goes back
to solving an earlier problem.
3.6.3 Interactive Search Options
Figure 3.5: Menu for Interactive Search Options
Options for the interactive search can be chosen by using theI-Searchcommand in the Profile menu
or by selecting theSet Optionscommand in the top-level interactive search menu. The option menu is
shown in Figure 3.5.
38
Choosing Operators
The first group of items in Figure 3.5 controls the application of an operator to a node. The first two
items are used for debugging while the last two are often used during planning. The first item forces a
Lisp break before and after each execution of theexpand-node function, which interprets an operator
to expand a node to the next planning level. The second item performs the same function, but only for
certain operators, which are chosen from a menu by the user. These two items can be used to stop
planning at a particular point, e.g., to set trace flags that track what happens when a particular operator
is applied.
The third item permits the user to select operators. By default, the system applies operators in the
order they are input. With this item selected, a menu will appear whenever more than one operator is
applicable at a node. From this menu, the user can choose an operator by clicking on its name, possibly
drawing or printing it first. The fourth item permits matching of the preconditions and constraints of
the operators before presenting the choices to the user. Only the matching operators are presented as
choices. This feature is ideal for domains like the missionaries and cannibals problem and has the
advantage of fewer choices. The disadvantages are that matching all operators decreases efficiency and
the user may never notice that certain operators were available but failed to match.2
Choosing Instantiations, Orderings, and Goals
The second group of options in Figure 3.5 gives the user choices for instantiations, orderings, and goals.
If the option of choosing operators for interactive instantiationof variables is selected, the system allows
the user to instantiate the local variables of selected operators whenever the operators are applied (from
a list of legal instantiations computed by the system). The option for choosing required instantiations
lets the user make choices whenever the system is forced to instantiate a variable and more than one
instantiation is possible. The third item in this group allows the user to choose which goal to expand.
By choosingyes , the user selects from a menu of names. By choosingmouse, the user uses the mouse
to select from the possible choices that have been highlighted. The fourth item allows the user to resolve
resource conflicts by choosing an ordering from a menu. The value of this option determines how the
conflict is presented — by highlighting nodes already drawn on the screen, by printing to the listener
pane, or by displaying a menu.
By selecting the option of choosing goals, the user can expand one part of the plan in as much detail
as desired without expanding other parts of the plan. Figure 3.6 shows the menu for choosing a goal to
solve. The second item copies the remaining goal nodes to the next planning level without solving them.
2This option decreases efficiency for two reasons: (1) often the system checks only one precondition (for the chosenoperator) instead of all of them, and (2) matching will be performed again when the operator is actually applied. In domainswhere operators have preconditions containing 20 predicates and plans may be hundreds of steps long, a precondition can takea second or more to match near the end of a large plan. Checking ten such preconditions could introduce a significant delay.
39
Figure 3.6: Menu for Choosing Goal to Solve with Mouse
These goals are delayed until the user chooses to solve them. The third menu item permits planning the
remainder of the current level without choosing goals, but the opportunity to choose goals will again be
available at the next planning level. The last menu item permits the user to set the global default for goal
choice.
The option to interactively order resource conflicts can make for a flashy demonstration. The con-
flicting nodes are seen flashing and then are highlighted while the user chooses an order. The ordering
link is then drawn while its beginning and ending nodes are flashed. The distributed SIPE–2 encoding
of the standard blocks world uses resources, so this capability can be shown by interactively solving
problems in the blocks world.
Additional Options and Customization
The last two groups of options in Figure 3.5 allow easy access to certain Profile-menu commands and
variables, particularly theSearch Space, Trace, andPlanningcommands. The option for displaying the
plan at each level allows values of:draw , :print , :use-menu , and:neither . The default is
:use-menu , which directs the system to query the user about the desired action after each new plan
level is generated. The:draw option is frequently selected when the user wishes to see the plan at
every level and it assures that the current plan is always displayed. The:print option is not generally
used within the GUI since the listener pane is small. The:neither option continues planning without
presenting the plan. The documentation below describes how to set this variable in an input file.
The option for flashing each node as it is expanded (and as ordering links are being added) is turned
on by default and helps the user to follow what the planner is doing. However, the plan being expanded
must be the drawing currently displayed in the GUI or nothing flashes. Another option allows flashing
of both nodes whenever an ordering link is being added. Finally, the number and length of flashes is
settable as this varies with the speed of your machine and the desired speed of planning and interaction.
The more important variables that are interactively set with theI-Searchcommand are listed below.
Their default values areNIL unless otherwise specified. Their values can be set in an input file to
40
customize problem solving:
fast-interactive-search [Variable]This variable specifies whether and how to present the new plan at each planning level. Legal valuesare :draw , :print , :use-menu , and:neither , corresponding to drawing the plan, printing theplan, querying the user with a menu, and continuing planning, respectively.
interactflg [Variable]If T, lets the user choose the operator to apply.
check-pc-before-choosing [Variable]If T and if interactflg is T, the system checks all preconditions before offering operator choices touser.
*user-chooses-goal* [Variable]If T, lets the user choose which goal to solve next.
automatic-allocation [Variable]If T (the default), the system automatically chooses instantiations for planning variables instead ofasking the user.
*interactive-res-conflict* [Variable]If non-nil, the user chooses resource conflict orderings interactively. The value can be:print ,:draw , or :use-menu . Any other non-nil value causes both printing and drawing of the resourceconflict.
3.6.4 Window Layouts with Choice Pane
SIPE–2 provides the option of using an additional window pane in the GUI, the choice pane, to facilitate
selection in the interactive search. Most choices in the interactive search use the choice pane whenever
the current layout includes one. Such a layout provides an easy way to view the possible choices before
selecting and is recommended when there are a large number of choices, because CLIM menus have
problems with numerous choices. A choice layout, available only with pull-down command menus,
is selected by clicking on theLayoutcommand in the Profile menu and selecting one of the following
choices:
Top Menu with Upper Interactor and Choice
Top Menu with Lower Interactor and Choice
Figure 3.7 shows a choice pane (in the lower right corner) during interactive planning in the mis-
sionaries and cannibals problem. The operator choices are listed in the scrollable choice pane. There
are four commands below the choice pane. Clicking on an operator name (thereby highlighting it) and
then clicking on theSelectcommand selects the operator. Clicking onDescribedescribes the currently
41
Figure 3.7: GUI with Choice Pane
selected choice and (be default) draws it in the graph pane. Clicking onSelectwill then restore the plan
drawing. The interactive search provides options with many choices — these can be selected by clicking
onOptions. Clicking onAbortaborts problem solving.
The following variable controls theDescribecommand when the choices are operators:
*describe-opr-in-popup* [Variable]Values can be:text for printing the operator,:graph-popup for drawing the operator in apop-up window with its own process, and anything else for drawing in the GUI’s graph pane.
3.7 Modifying Plans and Worlds: What-if Analyses
Sometimes it is desirable to modify a plan/problem or the initial world from which a plan must be
constructed. Three commands in the Plan menu support these modifications. In addition, a function that
supports “what-if” analyses is described in this section.
42
TheAdd Goalcommand first asks the user to enter a goal expression and then asks the user to click
on the node that should precede the goal. TheDelete Goalcommand asks the user to click on a node
and then deletes that node from the plan/problem.
Two commands prompt the user for a series of predicates and change an initial world. TheModify
command in the Domain menu can be used to change the predicates in a given world description. The
Add Factscommand in the Plan menu supports what-if analyses by changing the initial world in an
existing plan and analyzing the effect these changes have on the plan. UnlikeModify, Add Factsdoes
not change the knowledge base; rather it adds amother.nature node after the planhead and applies
both causal and state rules to deduce further consequences of the given predicates. (Modify applies
init deductive operators to its predicates.) Adding a node to the plan has two advantages: it allows the
application of causal rules, which cannot be applied to the first node in a plan, and it keeps a separate
record of the modifications and the original world.
Add Factsinvokes the algorithms of the replanner as described in Chapter 7. These algorithms may
change the plan, e.g., by removing inappropriate subplans, or by changing phantom nodes to goal nodes.
Thus, a final plan may become a partial plan afterAdd Factsis invoked.
Advanced concepts:A function, what-if , provides programmatic access to the capabilities in
theAdd Factscommand. However, it also invokes the replanner on the modified plan to generate a plan
for the new situation.
what-if preds &optional (plan *current-plan*) [Function]
This function takes a set of predicates, adds them to the original world of a plan, then calls the problemrecognizer and replanner to modify the plan to be valid in the new world. Theauto-replan variablecontrols whether the replanning is done in movie mode, interactively or automatically.Preds canbe a list of SIPE–2 predicate structures or a list of expressions to parse, e.g.,(not (on a b)) .The replanner sets the variables*current-plan* , lastplanhead , andanswer-names to theresulting plan, see Chapter 7.
3.8 Intermingling Planning and Execution
Advanced concepts:This section is for programmers and should be skipped by those not intending to
use this capability.
SIPE–2 has the ability to interleave planning and execution. Many planners plan every step of
each plan to the lowest level of detail. Such detailed planning can prevent the planner from reacting to
events as quickly as needed. Furthermore, as actions are planned further into the future, the probability
increases that some unexpected event will render them unsatisfactory.
There is no inherent reason that SIPE–2 has to plan everything to the lowest level of detail, so the
operator description language allows encoding of domain-specific information about which goals and
43
actions can have their planning delayed. Including the tokendelay in the description of a node in
the plot of an operator instructs SIPE–2 not to plan any such goal or action until a plan suitable for
execution has been generated. The planning of the delayed goals begins as a background job as soon
as the original plan is ready for execution. Alternatively, the tokendelay-execute can be used to
indicate that planning of a node should be delayed until execution of that node. This allows expansion
of a plan conditional on information gathered earlier in the plan execution. When SIPE–2 attempts
to execute such a node, its planning module is called. If the planning module fails, the system fails
execution, and if a plan is generated, then execution restarts on the new plan.
Goals should not be marked for delayed planning unless there is a high probability that they can be
achieved, or it is known that their solution is independent of the solutions chosen for prior goals. The
encoding of domain-dependent knowledge for delaying planning is effective because such knowledge
is generally available. For example, in the robot domain, the robot can obviously begin executing its
plan to get to the object to be picked up before planning how to deliver the object after picking it up
(assuming the robot does not make hallways impassable as it travels down them). Thus, the operator for
fetching and delivering an object should have a delay put on its second goal. Execution can begin with
some assurance that the initial plan is the beginning of a valid solution for the whole problem.
3.9 Overview of Automatic Search
Development of SIPE–2 has not addressed the issue of intelligent control of the search process in depth,
in part because searching algorithms and heuristics need to be domain dependent [8]. The system
searches through the space of partial plans depth-first by planning level (although this is breadth-first
relative to the individual goals in the plan), with chronological backtracking. Although SIPE–2 ma-
nipulates its representations efficiently, such a straightforward search will obviously not perform well
on large, complex problems if a solution is hard to find. The poor performance of automatic search is
not debilitating for two reasons: the system has been designed and built to support interactive planning,
and the operators are powerful enough to express metaknowledge that can be used to control the search
effectively by narrowing the set of applicable operators correctly.
The search is responsible for balancing time spent checking critics and the global constraint network
with time spent planning. How to achieve this balance is an open and important question, and the desired
result is domain dependent. In a domain where global constraints are frequently violated, it may be best
to check them after every operator application. This can be done in SIPE–2 by using the interactive
search. If, on the other hand, global constraints are almost never violated, it may be best to check
them only after a complete plan is produced. The default is to check the critics once every planning
level. The frequency of application (in planning levels) of various critics can be set as desired with the
Efficiencycommand of the Profile menu (see Chapter 15). Critics are always checked before a final plan
44
is accepted (unless their frequency is set to 0), so setting the frequency of a critic to a number higher than
the depth limit effectively applies that critic only on the final plan. The resource and clobber-brother-
goal (CBG) critics can also be applied more than once per planning level by setting the frequency to a
negative number and setting the following variables:
*cbg-opr-list* [Variable]
Value is a list of operators after which to apply CBG critic,T for all.
*res-opr-list* [Variable]
Value is a list of operators after which to apply resource critic,T for all.
Setting the above variables causes the respective critics to be called immediately after a node is ex-
panded by the given operator. It is recommended that the above variables be used only when absolutely
required (they have not yet been used in a SIPE–2 application). They are inefficient because the critics
look at the whole plan each time. It would be possible to write an “incremental” critic that looked for
conflicts in the newly generated nodes only, if such frequent critique were needed. More important, the
CBG critic often makes smarter decisions about resolving conflicts when it is analyzing several conflicts
and their interactions. Thus the extra expense of checking the CBG critic more frequently can result in
a worse plan.
PhantomizeGoals @
@@R
����
Apply Operatorsto Nonprimitive
Nodes
Copy Other Nodes,RecalculateDeductions
@@@R
����
Constraint-Satisfaction
Critic- Phantomize
Goals-
6if primitive plan withnew instantiations
ResourceCritic
- -Problematic-Interaction
Critic- Valid Plan at
Next Planning Level
Figure 3.8: Algorithm for Producing a New Planning Level
Figure 3.8 depicts how the search algorithm produces one planning level from the previous level.
The search begins by trying to phantomize any goal in the original problem (i.e., make the goal true with-
out applying an operator). It then applies an operator to each node in the plan that requires further spe-
cialization (i.e., to each nonprimitivegoal , process , or choiceprocess node, see Section 11.3).
During this application of operators, any intervening nodes (e.g., precondition nodes, primitive nodes)
adjacent to the nodes being expanded are copied to the new plan. The deduced effects of the copied
45
nodes are recalculated, since they may change in the different context specified by the more detailed
plan. The search checks for problems any of these operations may cause, and may change phantom
nodes back to goals, as well as rejecting operator applications that falsify preconditions already present
in the remainder of the plan.
After the above operations have created a plan at the new planning level, the critics are called on the
new detailed plan. They add any constraints necessary to ensure that the global constraint network can
be satisfied, then try to phantomize goal nodes, then check for resource conflicts, and finally check for
problematic interactions among unordered actions. Both of the last two operations may add ordering
constraints to fix conflicts or problems, which in turn may lead to nodes being added to or removed from
the plan.
Advanced concepts: This search has been built on basic mechanisms (primarily contexts) that
facilitate the ability of users to encode their own search strategies. For example, it would not be difficult
to implement a best-first search if there were a function to evaluate the utility of a partial plan. This
has not been done because of the difficulty in writing such a utility function. A programmer wishing
to implement his own search algorithm should begin by reading the code and comments in the file
search.lisp. In the search algorithm, each backtracking point is stored as a three-element list. The first
element is the operator to be applied, the second is the node to which it should be applied, and the third
is the plan object. A list of such backtracking points is kept at each planning level, and backtracking
involves trying the next backtracking point by removing the previous choice from the context and adding
the new choice of operator and node to the context. Note that the before-backtrack plan is stillaccessible
through its context. No backtracking points are kept for variable instantiationsor the additionof ordering
links. A programmer may choose to do this in a customized search.
46
Chapter 4
Drawing Plans and Other Structures
Once a domain has been input, the Drawings menu can be used to draw graphical representations of
various system structures. The commands in the Drawings menu were described in Section 2.1.4; this
chapter describes the forms of theDraw command and shows the types of output they produce. Ways
to customize the appearance of drawings are also described. The Profile-menu commandsDrawing,
Node Sizes, Node Colors, andNode Shapesallow customization of drawings, although the defaults are
appropriate for most domains. Each of the first three has its own section in this chapter. TheNode
Shapescommand allows setting of Grasper node-shape parameters, as described in the Grasper manual
[2]. Primarily, Node Shapesallows the setting of fonts and highlighting styles.
4.1 The Drawing Profile
TheDrawing command in the Profile menu brings up the menu in Figure 4.1. The first choice regards
using defaults for drawings. If the choice isyes , the system never displays the menu for labeling
and filtering a plan drawing (Figure 4.2). Ifno, the user always gets the chance to relabel and refilter a
drawing. The default is to let the user choose for plans but to use the defaults for operators and problems.
The second choice is to flash nodes as they are being expanded — this is the same variable that is
set during the interactive search (see Section 3.6). The next two choices control flashing when adding
orderings, and the length of flashing. The final choice in the first group is to horizontally stagger nodes
that are in parallel. For plans with more than two actions in parallel, staggering often looks better as
ordering links will not be vertical and will not overlap as often.
The second group of drawing profile choices allows filtering of nodes in the plan before drawing.
A plan contains nodes that represent information for the replanner and the search algorithm and are
not essential to understanding the plan itself. A user will generally want to see only the nodes that are
essential to the plan; thus, the default is to filter out all nonessential nodes. Phantom, precondition,
47
Figure 4.1: Profile for Drawing
choice, or degenerate-split nodes (i.e., splits that have been reduced to only one parallel subplan by
addition of ordering links or phantomization of parallel goals) are all filtered out of plan drawings by
the default settings in the drawing profile. Choice and degenerate-split nodes will generally never be
drawn except to show every node in the plan (e.g., during debugging). It may often be useful to view
phantom and precondition nodes. Also, after plan execution has begun, executed nodes are filtered
according to the flag for phantom, and nodes with explicit ordering links to parallel branches are always
drawn even if they would otherwise be filtered.
The third group of choices in the drawing profile determines how each node is labeled. The default
is to label nodes with the name of the goals or action, and the arguments, although the figure shows
a setting where textual descriptions are being used. Nodes are not labeled with their type because the
type is depicted by the shape and color of nodes in the drawing. For example, non-primitivegoal
nodes are turquoise hexagons,precondition nodes are brown rectangles,phantom nodes are gray
rectangles,split and join nodes are gray triangles, non-primitiveprocess nodes are turquoise
capsules, and primitive nodes are blue. The presence of a turquoise node indicates that the plan is not
yet completely specified.
48
4.2 Drawing SIPE-2 Structures
The Drawings menu can be used to draw system structures graphically and manipulate these drawings.
TheDraw command has several forms: operator graph, operator, problem, plan, plan decomposition,
world, and objects. Each of these commands causes a drawing of that type of structure to be created.
Figure 4.2: New View Menu for Labeling and Filtering a Plan for Drawing
4.2.1 Plans and Problems
Draw ProblemandDraw Plan let the user choose among all the defined problems/plans and then draw
that choice. Figure 2.1 shows the result of drawing an operator, while Figure 2.3 and Figure 2.4 show
the result of drawing more complex plans.
For all three of these commands, depending on the settings in the drawing profile, the user may see
the menu in Figure 4.2 which allows sizing of nodes, filtering of nodes, and labeling of nodes. This
menu always appears when the user clicks onNew View. The previous section describes the filtering
and labeling flags, and the choice of size is self-explanatory. When the menu in Figure 4.2 pops up after
clicking onNew View, there will also be a choice of plans to draw.
TheNew Viewcommand in the Drawing menu is frequently used to change the appearance of a plan,
problem, or operator drawing. For example, omitting arguments from the label and choosing a smaller
49
size may allow many more nodes to fit on the screen. When nodes overlap, try a larger size to make the
plan drawing more readable.
As of version 4.22, SIPE–2 expands the layout of plan drawings to avoid overlapping labels, thus
producing much more readable drawings. In addition, a new option for “expandable node icons” (on by
default) was added that allows the node icons to grow to enclose the node label. Expandable icons can
be disabled with either theNew Viewcommand or theDrawingcommand in the Profile menu.
Expanding layouts to avoid overlap of labels (the icons may sometimes overlap for small sizes)
works with or without expandable node icons, but incurs an additional computational cost that can be
significant if large plans must be drawn quickly. Expanding layouts can be disabled to speed up drawing
by one-third to one-half (or to get the same behavior as previous versions of the system). (For example,
a 150-node plan with large node labels draws in 8 seconds with expansion and 4.8 seconds without
expansion on an Ultra 1.) Expansion in either or both dimensions can be disabled with these variables:
expand-y-layout [Variable]
The value is a boolean. If T (the default), nodes are placed on the y-axis to avoid label overlap.
expand-x-layout [Variable]
The value is a boolean. If T (the default), nodes are placed on the x-axis to avoid label overlap.
With expandable node icons, the size chosen will not affect the appearance of individual nodes but
it will affect the layout — a larger size will spread the nodes out more, but only for sizes big enough to
prevent node label overlap (unless the expandable layout has been disabled). Without expandable node
icons, the size chosen also determines the size of the node icons, as it did in earlier versions of SIPE–2.
The last item in the menu forces reparsing of the plan drawing. Since drawing a large plan can take
time, SIPE–2 notices when no flags have been changed and does not redraw the plan. However, if the
planner has run since the original drawing and changed the plan without creating a new planning level,
then forced reparsing can be used to make the GUI reparse and redraw the plan without changing the
labels or filters. This can happen if a plan is drawn before the critics are applied, and the critics then add
ordering links or change goals to phantoms. Reparsing and redrawing the currently drawn plan can be
accomplished by simply clicking on theReparsecommand in the Drawings menu.
4.2.2 Plan Decompositions
The Draw Plan Decompositioncommand draws a decomposition graph showing the nodes in a
plan/wedge from the highest level to the lowest level, where links indicate the lower-level descendants
of a given node. A decomposition graph is useful for understanding how and why a plan was generated,
as well as for debugging.
50
The options for controlling plan drawings in Figure 4.2 also control a decomposition graph drawing.
The last options selected will be reused, or the user can choose to reset them. The user can choose the
root of the graph to be a plan name or the name of any node in the plan. Because the latter requires
a context, it is easiest to invoke theDraw Plan Decompositioncommand when the plan you wish to
decompose is already displayed (as this will generate the correct context as the default). If the root
specified is a planhead node or a plan name, then the entire decomposition for that plan is given from
the most abstract level. If some non-planhead node name is given as the root, then only the wedge rooted
at that node (down to the lowest level) is drawn.
There are additional options for decomposition graphs. The user can choose to browse the drawing
rather than draw it in its entirety. Only a few nodes around the root are drawn initially, and the user
can expand and contract the graph with mouse clicks. Browsing is particularly useful for large plans,
which otherwise would have the topmost nodes too spread out for easy visualization. The user can select
whether or not to draw exact copies of a node at the next lower level. (This is not done by default, but
may be useful in debugging when it is desired to see every action node in the plan.) The user can choose
whether the graph is laid out vertically or horizontally.
Control nodes (splits and joins) never appear in a decomposition graph, as these graphs do not show
temporal ordering of actions. Goal, process, and choiceprocess nodes are always drawn, and precondi-
tion and phantom nodes are drawn as directed by drawing profile choices. Node icons in decomposition
graphs always expand to surround the node labels. Hexagons expand poorly if the label height and width
are not similar, so goals use ellipses instead of hexagons.
4.2.3 Operators
TheDraw Operatorcommand lets the user choose among all the defined operators and then draw that
operator. The drawings of plots are controlled by the same options described for plans and problems,
including theNew Viewcommand.
The Draw Operator-Graphcommand displays the Operator Graph for the currently defined set
of operators. The Operator Graph is a forest of directed graphs in which the nodes are labeled by
operators. There is an edge from a node labeled OPR1 to another labeled OPR2 if and only if OPR2
could sometimes be applied in the immediate expansion of OPR1, that is, OPR2 could be used to expand
one of the nodes in the plot of OPR1. Class constraints on arguments of operators are taken into account
when generating this graph.
The user may only want to see a graph of the operators used to solve a particular goal. SIPE–2
provides three methods for specifying the root of the operator graph (on a menu that appears when
Draw Operator-Graphis invoked):
51
A predicate: The user enters a predicate (with completion) and the system displays enough graphs to
include all operators that can be used to expand that predicate. The predicate can have arguments
that are class names, object names, numbers, or sipe variable names. The latter are converted
to class names (i.e., two occurrences of the same name will NOT be the same variable, each
argument is unique.) Classsort-hierarchy should be used to match anything, and is used to
replace any unknown names.
An operator: The user selects one of the defined operators from a menu, and a graph is drawn with
this operator as the root.
A list of operators: The user selects a set of operators from a menu, and enough graphs are drawn to
include all selected operators.
TheDraw Operator-Graphcommand is particularly useful for understanding the structure of a set
of operators that have been written by someone else.
4.2.4 Initial World
TheDraw Worldcommand displays the initial world predicates graphically. It lets the user select spe-
cific predicate names or ask for all of them. The user can also choose to print the number of instances of
each predicate name as a summary. Figure 4.3 shows the result of asking for the NEXTTO, OPEN and
CONTAINS predicates as well as the summary of predicate instances to be drawn in the robot world.
TheDraw Objectscommand draws the sort hierarchy. It lets the user pick the class below which
to draw the hierarchy, and pick whether or not to draw the instances as well as the classes. Classes are
drawn as capsules and instances as rectangles. Objects defined by the system are in blue and objects
defined by the domain are in red. If the sort hierarchy is large, thePrint Objectcommand can be used
to print information about the size of classes before drawing them (see Chapter 5). SIPE–2 generates
a root node which is pointed to by the global variablesort-hierarchy . Any input class that has
no parent becomes a subclass of this root. Figure 4.4 shows the result of drawingsort-hierarchy
without instances in the robot world.
4.3 Browsing
Browsing allows partial viewing of a drawing and is useful for large drawings, particularly plan de-
compositions, which otherwise would have their topmost or leftmost nodes too spread out for easy
visualization. TheBrowsecommand draws only a few nodes of the current drawing and the user can
then expand and contract the drawing with mouse clicks.
52
Figure 4.3: Drawing of Predicates in Robot World
Browsing can be performed on drawings of objects (the sort hierarchy), plans, plan decompositions,
and operator graphs. Except for plan drawings, the option of browsing can be selected as an option
before drawing, thus avoiding creation of a large drawing. Plan drawings are often created without a
parameter menu, so currently they can only be browsed by first drawing them and then clicking the
Browsecommand. In addition, plan drawings a more attractively laid out when the entire plan is drawn
(and the system’s special layout algorithm is used.) Browsing layouts are best suited for trees, such as
plan decompositions and the sort hierarchy.
Browsing creates its own Grasper space, which is abrowsing space. In browsing spaces, nodes with
bold labels can be further expanded. Left clicks on nodes expand them (or print them in a window if
they have already been expanded), and middle clicks contract a node’s expansion. If a mode with many
children is expanded, only some fixed number of them will be drawn. There will be a child node with a
bold label beginning with “ZZZZ” and clicking it will draw more of the sibling nodes. A right click exits
browse mode. Invoking theBrowsecommand on a browsing space will restart browse mode without
changing the current state of the drawing (except for possibly recentering it).
53
Figure 4.4: Drawing of Classes in Sort Hierarchy in Robot World
4.4 The Birds-Eye–View Window
Large drawings do not fit in the graph pane in their entirety; therefore, the graph pane is a scrollable
viewport onto the entire drawing. The birds-eye–view window provides a low-resolution view of the
entire drawing that is scaled to fit completely in one window. The birds-eye view is useful for visualizing
and navigating through a large graph. Figure 4.5 shows the birds-eye view of a plan that is too large to
fit on the screen. TheBirds Eyecommand in the Profile menu controls what is displayed in the birds-eye
window.
The user can manipulate the birds-eye window when inbirds-eye mode, which is entered by middle-
clicking on the background of the graph pane. In birds-eye mode, the user can select commands from a
menu of the following items:
� Scroll Graph — A rectangle within the birds eye shows the position of the graph pane viewportwithin the entire graph. The user can reposition this rectangle to a new position in order to scrollthe graph pane. After selecting this menu item, left click in the background of the birds-eyewindow and drag the rectangle to a new position.
54
Figure 4.5: Birds-eye View of a Large Plan
� Return To Graph — This command exits birds-eye mode and returns to the GUI command level.
� The remaining commands in the birds-eye mode menu are still under development and are not yetimplemented. They should not be used.
4.5 The Node Sizes Profile
The Node Sizescommand in the Profile menu controls the size and spacing of nodes in drawings.
Five sizes are already defined in SIPE–2: (tiny small medium large jumbo) . Each of these
names is set to a list of four numbers which represent the x-radius, y-radius, x-spacing, and y-spacing.
TheNode Sizescommand gives a menu for changing these numbers for the five system sizes, and choos-
ing which size will be the default. (The user can define his own size by adding its name to the listsizes
and setting the name to a list of four numbers.)
The x-spacing and y-spacing specify how much horizontal/vertical space to put between nodes in a
drawing, given as a fraction of the radius of a node. Smaller sizes get more nodes on the screen at once,
but may cause node labels to overlap each other. Similarly, lower values for x-spacing and y-spacing
for a given x-radius and y-radius also gets more nodes on a screen at the cost of possibly overlapping
labels. For plans with many parallel actions, it may look better to increase the y-spacing number.
TheRescalecommand in the Drawings menu is useful for shifting, shrinkingor expanding a drawing
layout in either the horizontal or vertical direction, or both. TheMagnify command can be used to
(imperfectly) expand or shrink a drawing, including the font.
55
4.6 Customizing Drawings
Several options are available for changing the appearance of plan drawings.
� Many labeling and filtering options in theNew Viewcommand affect the node labels.
� The size for one drawing can be changed with theNew Viewcommand or the default size can bechanged with theNode Sizescommand. Larger sizes use more spacing during layout and largernode icons when expandable node icons are not being used.
� The user can define a new size with a larger x-radius, x-spacing, y-radius, and y-spacing, usingtheNode Sizescommand in the Profile menu.
� The Rescalecommand can shift, shrink or expand a drawing layout in either the horizontal orvertical direction, or both.
� If the label font is too small or too large, it can be changed with either theNode Shapescommandor theMagnifycommand. With the latter command, all magnifiable drawings (which include allSIPE–2 drawings) in the current Grasper graph are expanded to any of a number of prespecifiedfont sizes. This command also affects all future drawings in this Grasper graph, so one mustreturn the size to ”normal” to get the default drawing behavior on future drawings. Magnificationimperfectly expands the layout.
� Abbreviations and text descriptions can be used in labels.
To change the defaults for node labels in drawings for a given domain, the following vari-
ables from theNew View command can be set:name-flag , id-flag , args-flag , and
time-constraints-flag .
vp-print-id [Variable]
This variable controls how uninstantiated variables are printed and drawn. IfT, only theid is printed.
If NIL , only the name is printed. If:both (the default), both the name andid are printed (e.g.,
airport.1-N73).
4.6.1 Abbreviations
Advanced Concepts:This section is intended for programmers only.
The user may prefer to see shorter (or longer) names for actions and objects that the names used in
the database. The variable*abbreviations* can be set to an association-list where each element
gives an abbreviation for actual object names. Options described below specify when to use abbrevia-
tions: the default is to use them in drawings, while using long names in printing. Here is an example for
beer drinkers:
56
(setq *abbreviations* ’((375ml-a-bitter-terrapin bitter)(375ml-a-stout-fennario stout)))
The following variables are used for abbreviations. Setqs for these variables can be put at the end of
any SIPE–2 input file.
*abbreviations* [Variable]Value is an a-list of object names and their abbreviations.
*attribute-names* [Variable]Value is an a-list of sort-hierarchy attribute names and their abbreviations.
*use-abbreviations* [Variable]A value of:graphics uses abbreviations in drawings,:text uses abbreviations in printing,:both uses abbreviations in both, and:neither never uses abbreviations.
4.6.2 Text Descriptions
Advanced Concepts:This section is intended for programmers only.
SIPE–2 allows the specification of parameterized textual descriptions for goals, actions, and op-
erators. These can be used in either plan drawings or the printed versions of nodes and plans, thus
presenting a much more English-like interface to the user.
The domain knowledge must provide parameterized format strings, called documentation strings,
for appropriate textual descriptions. This can greatly increase the user friendliness of both the GUI
drawings, and printed node descriptions.
The use of these documentation strings in GUI drawings is controlled by the variablename-flag ,
which can be set by theNew Viewcommand or theDrawing Profile command. The value of
name-flag should be:text-description to use documentation strings, and normally argu-
ments would not be printed in this case, because the documentation strings include them. Documenta-
tion strings are always printed when nodes are printed or displayed in their entirety.
Add this to a domain load file to use documentation strings in GUI drawings:
(setq name-flag :text-description args-flag nil)
There is no need to have documentation strings for all actions/operators/predicates. The system will
always revert to its non-documentation labeling for any entity that does not have a documentation string
defined.
The variable*documentation-strings* stores documentation strings for predicates describ-
ing the world state,*goal-documentation-strings* stores documentation strings for predi-
cates in plan nodes, and*action-documentation-strings* stores documentation strings for
actions and operators. When printing predicates or actions in certain situations, e.g., during theDraw
Worldcommand or during drawing of plans, the system uses Lisp’s format function applied to the doc-
umentation strings to print the object.
57
Predicate Descriptions
Each element of the lists *documentation-strings* and
*goal-documentation-strings* is of the form (predicate-name argument-list
format-string) . One primary purpose of the argument-list is to determine the predicate’s arity
(number of arguments). (Different format strings can be specified when the same predicate name
is used with a different number of arguments.) The argument-list can be of two forms: (a) a list of
symbols or (b) a list of integers.
Case (a): only the length of the list matters, and it is used to determine the arity of the predicate.
The symbols can be anything. The format-string must use arguments in the same order as they appear
in the predicate.
Case (b): the first integer is the arity of the predicate. The remainder of the integers represent the
arguments to the format string. N means the Nth argument of the predicate will be used that argument to
the format string. Thus, (4 2 3 2) means that the predicate has 4 arguments, and the format string would
have 3 arguments, and they would be, in order, the second, third, and second arguments of the predicate.
Here is an example using each syntax:
(setq *DOCUMENTATION-STRINGS*’((carton-packing-rate (packaging-line1 packing-rate1)
"Line ˜S packages ˜S thousand cartons per hour")(severe-shortfall (product1) "There is a severe shortfall of ˜S")(beer-tank (beer-tank1 cellar1 numerical1)
"˜S is in cellar ˜S and holds a maximum of ˜S hectolitres")))(setq *DOCUMENTATION-STRINGS*
’((operative (1 1) "˜S is operational")(carton-packing-rate (2 1 2)
"Line ˜S packages ˜S thousand cartons per hour")))
Action and Operator Descriptions
Each element of the list*action-documentation-strings* is of the form(action-name
format-arguments format-string) .
Action-name is the name of a primitive action or operator. Format-arguments is a list of integers,
one for each argument to the format string. N means the Nth argument of the action/operator will be
used as that argument to the format string. Thus, (2 3 2) means that the format string would have 3
arguments, and they would be, in order, the second, third, and second arguments of the action.
Here is an example:
(setq *ACTION-DOCUMENTATION-STRINGS*’((row-1-m (5) "Row 1 missionary˜% to ˜A")
58
(row-2-m (5) "Row 2 missionaries˜% to ˜A")(row-2-c (5) "Row 2 cannibals˜% to ˜A")(row-1-c (5) "Row 1 cannibal˜% to ˜A")(row-mc (5) "Row 1 cannibal and 1 missionary˜% to ˜A") ))
The following variables are useful for customizing the textual output of SIPE–2. Setqs for these
variables can be put at the end of any SIPE–2 input file.
*documentation-strings* [Variable]Value is an a-list of a predicate name and printing instructions, used in printing predicates describingthe world state.
*goal-documentation-strings* [Variable]Value is an a-list of a predicate name and printing instructions, used in printing predicates in plannodes.
*action-documentation-strings* [Variable]Value is an a-list of an action or operator name and printing instructions, used in printing processnodes in a plan.
4.7 Colors in Drawings
In all drawings, SIPE–2 uses colors to distinguish different types of nodes. In SIPE–2 plans, all open
nodes, i.e., those needed expansion at next level, whethergoal , process , or choiceprocess , are
in turquoise, primitive actions are in blue,phantom nodes are in gray, andprecondition nodes are
in brown. These colors are for icons only, the text for labels is red. Thus, a plan containing a turquoise
node is not yet complete.
SIPE–2 makes all actions added/modified during replanning stand out in drawings. These actions
have slightly thicker node icons, and have purple (the value of*replan-node-color* ) labels in-
stead of red. (For monochrome monitors, the label font is made bold and larger). This property is reset
on each call to the replanner, so only applies to the changes from the most recent replan.
On monochrome monitors, the default is to draw precondition and phantom nodes with gray
borders. In the CLIM implementation, this appears to slow down the whole drawing by an or-
der of magnitude. Drawing is still fast for plans with dozens of nodes, but for plans with hun-
dreds of nodes it is recommended that an alternative drawing style be defined by loading the file
sipe:sipe;clim-draw-methods . This problem does not affect color monitors.
While a pleasing color scheme is provided, the colors can be changed using theNode Colorscom-
mand in the Profile menu. It allows setting of colors for many different types of drawings. In addition,
the colors of the window panes in the GUI can be set with theColorscommand. In all cases, new colors
are selected from a tree of menus of colors and color groups. To view colors before selection, the user
59
can input the graphgrasper:graphs;shape-palette.graph and display the various spaces
in that graph.
The file colors.lisp contains the following useful functions relating to colors:
save-colors &optional (menu *node-color-menu*) [Function]
This function writes setqs for all variables in the given menu to debug-io (the emacs window). Thisis useful for setting colors in an initialization file. The menus used inNode ColorsandColors are*node-color-menu* and*pane-color-menu* , respectively.
black-and-white [Function]
This function makes all nodes and panes be black on white. This is useful when saving screen dumpsfor printed documents.
default-colors [Function]
This function restores SIPE–2 to its default colors.
4.8 Customizing Node Shapes
Advanced Concepts:This section is intended for programmers only.
A Grasper node shape defines how a node is drawn (color, label, icon, and so forth). SIPE–2 has
node shapes defined for each type of node and supports the following capabilities:
1. Other applications building on top of SIPE–2 and defining their own special node shapes for nodeswith particular properties. Special node shapes are used for replanned and advised nodes withinSIPE–2.
2. Users interactively modifying the node shapes (with theNode Shapescommand in the PROFILEmenu), and then with one click restoring the node shapes to saved system defaults.
3. Other applications and users redefining the system node shapes.
4. Automatically redefining all known node shapes (system and special) based on type of monitor,when first entering the SIPE–2 application in the GUI.
Programmers familiar with Grasper can use the following variables to customize the drawing of cer-
tain nodes, as is done in the multiagent version of SIPE–2 (see the filempa-colors ). This capability
requires writing a predicate function that determines whether a specific node should be customized, and
writing a Grasper node shape for drawing such nodes. This allows the full power of Grasper to be used
for drawing customization.
SIPE–2 uses the following variables to implement special node shapes and uses them to provide
different colors in nodes changed by replanning or advice. To add your own node shapes, push values
onto the first variable below.
60
*special-node-shapes* [Variable]The value of this node is used to customize the drawing of certain nodes. The value is a list of dottedpairs. The car of each pair is the name of a predicate (LISP function) of one argument (a plan node)that tells whether the given shape applies to this node. The cdr of each pair is the name of the Graspernode shape to be used for display of nodes satisfying the predicate. If a node matches more than onepredicate, the last matched entry in this list will override earlier entries.
default-special-node-shapes [Variable]This value is used to reset*special-node-shapes* every timeSIPE–2 is reset. It is assumednode shapes not on this list are specific to domains. Setting this variable changes node drawingsacross all domains. The default value is:
((color-advised-node? *advised-node-shape)(replan-action? *replan-node-shape))
There is one complication in defining node shapes. They are specific to the type of monitor being
used. In particular, SIPE–2 defines different shapes for monochrome monitors than for color monitors
(distinguished by the variable*MONOCHROME-MONITOR?*). SIPE–2 therefore calls functions to de-
fine the shapes when it first enters the SIPE–2 application in the GUI (otherwise, a saved image will
have the shapes for the monitor used to originally load the code).1
User specified shapes must be defined by functions specified in the following variables. Note that
these variables must be set before the GUI is created.
set-user-default-node-shapes [Variable]This variable can be set to a function of no arguments that defines defaults for special node shapes.TheSIPE–2 functionset-default-node-shapes should be used as a model. This function iscalled when theSIPE–2 application is first selected in the GUI.2 This function can also redefine systemdefault node shapes.
set-user-node-shapes-from-defaults [Variable]This variable can be set to a function of no arguments that restores the current node shapes fromdefaults specified in the previous function. TheSIPE–2 functionset-node-shapes-from-defaults should be used as a model. This function is calledimmediately afterset-user-default-node-shapes , and when the user interactively restoresdefault node shapes.
*set-node-shapes-function* [Variable]This variable is used to replace system default node shapes with custom shapes. The value can be afunction of no arguments that defines defaults for all node shapes, both domain-specific and all thoseused bySIPE–2.
1The shapes default to those for a color monitor, so the GUI can be used to draw plans without ever entering the SIPE–2application in the GUI for color monitors.
2This selection happens whenever SIPE–2 is selected from the Application menu, or when the function(run-sipe) iscalled. However, creating the GUI with another function (such asrun-grasper ) will not select SIPE–2 or update its nodeshapes.
61
4.9 Miscellaneous Customizations
TheRescalecommand in the Drawings menu is useful for shifting, shrinking or expanding a drawing in
either the horizontal or vertical direction, or both.
SIPE–2 allows customization of flashing of nodes. When requested in the planning profile or in-
teractive search, flashing of nodes is done at various times during planning, e.g., when adding ordering
links or expanding a node. The following variable controls the length of the flashing.
*flash-link-defaults* [Variable]This variable controls the number of times a node is flashed and the length of time each flash lasts. Thevalue of this variable should beT, NIL , or a list of two numbers. The first number is the number oftimes a node is flashed, and the second number is the length in seconds of each flash. A value ofNILinhibits flashing, and a value ofT uses the default value which is 2 flashes of 0.2 second each.
62
Chapter 5
Printing Data Structures
Many commands in the GUI print lexical output on the listener pane, to a pop-up window, or to a browser
with hyperlinks to other SIPE–2 objects. This chapter describes these commands, and helps explain the
output (for programmers only). Since there is little room for lexical output on the GUI Lisp listener, the
use of these printing commands from a Lisp listener window is also described. Abbreviations can be
used in printing as described in Section 4.6.
5.1 Printing in the GUI
Once a domain has been input, the Domain menu can be used to print lexical representations of various
system structures. This section describes the seven forms of thePrint command and shows the types
of output they produce. Before printing, thePrinting command in the Profile menu allows setting of
defaults for controlling how much information is printed foreach node, whether output goes to the GUI,
browser, or a pop-up window, and filtering flags (similar to those used in drawing plans) for printing
only certain types of nodes in plans. Printing of nodes can default to either a short version or a long
version. The short version prints only one line per node, while the long version prints as many lines as
needed to depict the information in the node.
Many pop-up windows have their own process and therefore stay around until they are dismissed.
This allows, for example, several windows to each display an operator while the user compares their
differences.
Most of thePrint commands are self-explanatory. The system generally puts up a menu of all known
instances of the particular structure and prints the one selected by the user according to the defaults set
in the profile. Chapter 9 describes an option for typing names with completion when the number of
choices is above a specified threshold.
63
Figure 5.1: Menu for Printing a Plan
A few commands provide additional functionality beyond what can be obtained by drawing.Print
Objectpops up a menu that has several options for printing information about the sizes of classes in the
sort hierarchy.Print Nodeallows printing of almost any internal data structure, which can be useful to
the programmer as described in Section 5.4. Clicking onPrint Plan and selecting a plan displays the
menu shown in Figure 5.1. This menu offers choices of how much to print for each node, which nodes
to print, whether to write the output to a file, the screen, or a pop-up window, and whether to print just
the lowest-level plan or every abstraction level of the plan.
5.2 Printing without the GUI
There is a macro,emacs-windowthat can be used inside the GUI to direct output to the*debug-io*
stream, which if often the Emacs window from which SIPE–2 was invoked. For example,
(emacs-window (dispnode P13)) will print the description of node P13 to the Emacs window
instead of the CLIM GUI. This is useful for saving the output in a file or sending it in an email message.
Some commands, e.g., printing a plan from the Domain menu, already allow output to a file. Output
can be permanently directed to the*debug-io* stream with the function(output-to-emacs) ,
described in Chapter 10.
SIPE–2 can also be run, without graphics, from any Lisp listener on Symbolics, or the window
running the main Lisp process on Suns. Because of the small size of the GUI Lisp listener, it is often
64
Figure 5.2: Display Menu
advisable to develop and debug applications by running SIPE–2 in such a window,1 or by directing
output to the*debug-io* stream.
The display menu, shown in Figure 5.2, can be obtained outside the GUI by calling the functions
(displaypkg) or (d) , or clicking onDisplay in the top-level menu. Inside the GUI, these func-
tions create an additional GUI. This menu contains most of the important printing commands from the
Domain and Plan menus of the GUI.
The first five items in the display menu are the same as the correspondingPrint commands in the
Domain menu.Name AbstractionsandRegroup Parallelare the same asAbstractandRegroupof the
Plan menu.
The following global variables allow access to system structures:
lastplanhead [Variable]Value is the last planhead node used by the planner.
operators [Variable]Value is a list of operators in the domain.
problems [Variable]Value is a list of problems in the domain.
state-rules [Variable]Value is a list of state rules in the domain.
causal-rules [Variable]Value is a list of causal rules in the domain.
1On Suns, the CLIM root window must be initialized, e.g., by calling(run-sipe) and then exiting.
65
init-operators [Variable]Value is a list of init operators in the domain.
5.3 Customizations
Variables for using abbreviations in both printed text and drawings are given in Section 4.6. The follow-
ing variables control the output of printed text:
*print-to-popup* [Variable]If the value is:browser (the default), many texts (including nodes, operators, and lists of operatorsbut not plans) are printed to a browser with hyperlinks to otherSIPE–2 objects (currently onlyNetscape is supported). Plans are printed to a (CLIM) pop-up window. If the value is any other non-nilvalue, large texts are printed to a pop-up window. If the value isNIL , all texts are printed to the Lisplistener.
*describe-opr-in-popup* [Variable]This variable controls how operators are described during the interactive search. If the value is:browser (the default), they are printed to a browser with hyperlinks. If the value is:graph-popup , they are drawn (as a graph) in a pop-up window. If the value is:text , they areprinted as directed by*print-to-popup* . If the value is anything else, the operators are drawn inthe graph pane (thus replacing any plan drawing that existed).
big-lnlength [Variable]This variable is the line length for printed text. The default is 72.
vp-print-id [Variable]This variable controls how uninstantiated variables are printed and drawn. IfT, only theid is printed.If NIL , only the name is printed. If:both (the default), both the name andid are printed (e.g.,airport.1-N73).
The following variables control how the browser is started. Currently only Netscape is supported.
*browser-image* [Variable]The value is a shell command that starts the browser and accepts a URL on the command line. Thedefault is"netscape" . The system currently assumes this command will accept the options“-display” and “-remote”.
*browser-options* [Variable]The value is a string of options added after the URL on the command line when starting browser. Thedefault is"-install" .
The following variables can match the size of pop-up windows to a given monitor:
*popup-text-size* [Variable]The default is :normal. Any legal CLIM font size can be used.
66
*max-popup-width* [Variable]The default is 1050.
*max-popup-height* [Variable]The default is 830.
5.4 Printing Internal SIPE-2 Structures
Advanced Concepts:This section describes capabilities of thePrint Nodecommand and should be
read only by programmers.
The Print Nodecommand in the GUI allows printing of any node that is drawn in the GUI. The
functions described here can be used to print any type of SIPE–2 node, including plan nodes, planning
variables, instances and classes in the sort hierarchy, operators, and predicates. Each object (except
predicates) has a unique name that points to the structure, is stored in itsid slot (see Appendix F.3), and
is often part of its printed representation. This makes it easy to get a pointer to a structure. For example,
printing a plan enables the programmer to get pointers to any variable, object, or plan node that occurs
in the plan.
For context-dependent nodes such as plan nodes and planning variables, the proper plan object must
be given (to provide the context) in order to see all the current constraints and instantiations.
dispnode node &optional plan-con [Function]
This function prints any internal sipe object to the*sipe-output* stream (generally the GUI lis-tener). The value ofplan-con should be a plan object (but can also be a cpp-list).
dinode node &optional plan-con [Function]
Calls dispnode after redirecting the output to the current window, and defaultingplan-con tosomething reasonable for plan nodes.
dispnode-popup node &optional plan-con [Function]
Calls dispnode after redirecting the output according to the value of the variable*print-to-popup* .
dnode [Function]
This function bring up a menu asking for the node name and output destination. It callsdispnode ordispnode-popup with the given node.
display-in-browser node-name-or-url &key executable node-action [Function]
67
Figure 5.3: Menu for Printing Data Structures
If node-name-or-url is a string, this function interprets the string as a URL and displays it in abrowser. Ifnode-name-or-url is a symbol bound to any type of SIPE–2 object, this function willprint the object to a browser with hyperlinks to other objects.Executable defaults to the value of*browser-image* , and is a string for the shell command to run the browser. This function first triesto display remotely in an existing browser, if that fails, a new browser is started.
The printing can be modified bynode-action , which defaults to “Inspect” causing the standardprinting of the object. Another action is “Derivation” which prints the derivation of a plan node, showinggoals and operators used from the given node up to a top level goal. The Web Server uses other actions,but they require a current plan drawing in the Web Server.
Example calls todisplay-in-browser :
(display-in-browser ’p300 :node-action "Derivation")
(display-in-browser ’p300)
The functiondnode can be invoked by clicking onNodein the Display Menu, which displays the
menu shown in Figure 5.3.
The option for printing all constraints is particularly useful for planning variables. Seeing all the
constraints on a variable is often essential for determining why the variable did or did not unify with
some object or some other variable. Figure 5.4 shows the display of planning variable N0268 in a
mobile-robot plan. The name of the variable was obtained by printing or drawing a plan that contained
it. The variable has severalpred constraints which constrain it to be either conf-door1 or conf-door2,
and finally aninstan constraint chooses conf-door1.
When the system is printing or drawing plans, variables that are instantiated in the given context
simply have their instantiation printed. To find the name of a variable (so that it can be displayed
with all its constraints), simply display a plan node containing the variable with a context ofNIL . The
variable will then have no instantiation in the given context. If the context had been given asNIL in
the menu that produced Figure 5.4, the system would have printed every constraint on the variable and
68
Figure 5.4: Displaying a Variable during Robot Planning
the choice point to which the constraint was attached. In Figure 5.4, only the constraints in the given
context were printed (without the choice points). This is generally much more useful, so care must be
taken to have the correct context when printing a variable.
69
Chapter 6
The SIPE-2 Web Server
The SIPE–2 Web Server makes a small subset of the functionalities of SIPE–2accessible via the World
Wide Web. In particular, interactive planning is not available although advice scenarios can be chosen.
However, new capabilities are provided, such as following plans by clicking on hyperlinks in the printed
description of a node.
The capabilities of the Web Server include:
� Generating a plan entirely automatically (optionally selecting an advice scenario).
� Generating a plan level-by-level, finishing automatically when desired.
� Drawing a plan.
� Drawing or browsing a plan decomposition.
� Drawing or browsing the sort hierarchy.
� Drawing or browsing operator graphs.
� Listing all operators with hyperlinks.
� Inspecting nodes, with hyperlinks in the output to enable easily moving from an inspection of onenode to its related nodes, variables, objects, and operators.
� Inspecting derivations, with hyperlinks to both other nodes and operators.
� Various commands for finding objects, predicates, resources, predecessors, successors, and paral-lel nodes. These redraw the plan with different colors for nodes of concern.
The primary objective of the Web Server is to allow remote users to generate and view plans, without
the SIPE–2 software and from any environment that supports a browser (e.g. MS Windows).
The application is multi-user. All users must use the same domain, (domain change disallowed
when more than 1 user). Users are terminated by an idle timeout (around an hour). There is a global
70
timeout (currently 4 hours) invoked even if user is still active. The SIPE–2 Web Server is based on
two additional applications CL-HTTP and CWEST, which can be distributed with SIPE–2. CL-HTTP
provides a server and produces HTML pages, and CWEST generates GIF images from the SIPE–2 GUI.
6.1 Running the SIPE-2 Web server
As of version 6.0, the WWW subsystem is loaded by default. To use SIPE–2 without loading the WWW
subsystem and CL-HTTP, give the argument:subsystem :core to load-system . The WWW
subsystem can later be loaded with(load-www) .
To start the Web Server, evaluate (sipe-ws ) or (sipe-ws :public t) . The former includes
all domains, including military domains, which require permission toaccess and are not normally dis-
tributed with SIPE–2. The latter only includes non-military domains and can beaccessed by anyone.
After starting, the server prints a URL for accessing it, for example:
http://Moonlight.AI.SRI.COM:8000/ , which can be given to users.
To kill the server process, evaluate (stop-ws ) or (stop-www-server ).
To run the Web Server on your own planning domains, add your domain descriptions to the
variables *domains* , *default-domain* , *domain-choices* , *public-domains* ,
and *public-domain-strings* (see globals-customize.lisp). Each domain must set
*domain-name* to its name, and this name must be used in the domain descriptions used by the
variables below.
start-www-server &key sipe-domain public port host domain [Function]
This function starts a Web Server running on your local machine. The keywordsipe-domain canprovide the name of a known domain which is loaded initially. Theport can be specified, but defaultsto 8000 ifpublic is t, otherwise a different port. Ifpublic is non-nil, only the non-military subset ofSIPE–2 domains are included in the server. (At other sites, the military domains may not be available.)The server is run on the machine found by looking at the Unix environment variables DOMAINNAMEand HOST. Alternatively, thehost anddomain keywords can provide these values. If the keywordsare not given and the Unix variables not set, the system will query the user for the host and domain.
sipe-ws &key sipe-domain public port [Function]start-ws &key sipe-domain public port [Function]
There are two shorter names for invoking a Web Server. They callstart-www-server with thegiven keywords.
stop-ws [Function]stop-www-server [Function]
These functions halt all servers running in the current image.
71
6.2 Known Bugs
The back button in the server frame relies on Javascript and does not work on some browsers. The back
button of your browser can be used instead, although it may roll back the command frame as well as the
display frame.
Some browsers and machines cannot display very large GIF files, depending on memory and cache
availability. Large military domain plans may overstress some browsers/machines (e.g., only our more
powerful Ultra 1s can draw the GIF for our largest military domain plans.
NOTE: please do not solve Air-Superiority or Offensive-Air-Superiority goals in the Air Campaign
Planning (ACP) domain, or draw the entire operator graph or objects hierarchy. This will peg the CPU
on the server for 2 to 7 minutes. Browsing instead of drawing is fine.
6.3 Example Web Server session
This section describes how a user can interact with SIPE–2 Web Server to note its capabilities. It is
assumed that you have already gone to the Web Server URL in your browser. Nodes drawn by the Web
Server are mouse sensitive, and clicking on them invokes a “node-click” action, which can be set to a
number of different actions in the interface. (Note: the displayed Node-click action may not be current.
You must clickSet Node-click Action to send the action to the Web Server.)
� Welcome page: enter your name and clickEnter SIPE-2.
� Select domain page: clickUse Current Domainif there is one, else pick a domain. You can onlychange domains if you are the only user. Missionaries-and-Cannibals is recommended for quicklychecking things out. For military plans, choose Air-Campaign-Planning-Granola, but solve onlythe smaller problems of Breach-Defense and Defensive-AS.
� Read instructions displayed on the browser if this is your first time.
� Commands menu: click DO IT with the Generate Plan command selected.
� Plan menu: click Generate Plan.Optional: choose a problem first.Optional: choose advice if it exists (in the ACP domain, TIE-PLAN1 is fastest, and some prob-lems will not solve if you pick NO-ADVICE).
� Click on some nodes in the plan (Inspect should be the node-click action) and see their details.
� Click on hyperlinks in the node description to see related nodes, objects (in the ACP domain, theobjects have interesting properties), and operators.
72
� You can use the BACK button to return to the plan drawing. (If this fails on your browser, be sureJava-script is enabled. You can also try the browser’s back button. If you cannot get back, clickReturn to Commands, then executeDraw Plan or Decompositionto restore the plan drawing.)
� Click Return to Commands. Make sure the plan is drawn again.
� Commands menu: SelectDerivationas the node-click action, then clickSet Node-Click Action.
� Click on nodes in the plan. You will see how they were derived, going back to the most abstractplanning level. Click on hyperlinks to see goals or operators used for expansions.
� Commands menu: Now selectDraw Plan or Decompositionand clickDO IT/Plan-draw.
� Draw menu: Pick the plan you want and clickBrowse Plan Decomposition. This draws thetopmost goals that were expanded to produce the plan. This also sets the node-click action toExpand.
� Click on the fringe nodes with bold labels to further expand the decomposition. Clicking onalready expanded nodes will Inspect them. Optional: set the node-click action to Contract, andclick on a node to contract its expansion.
� Click Return to Commands.
� Commands menu: Now selectDraw Objects Hierarchyand clickDO IT/Plan-draw.
� Draw Objects menu: In military domains, clickBrowse Objects Hierarchy. In smaller domains,you can clickDraw Objects Hierarchy.
� Again click on nodes to expand, contract, or inspect them, after selecting the desired node-clickaction.
� Click Return to Commands.
� Commands menu: Now selectDraw KB Operator Graphand clickDO IT/Plan-draw.
� Operator Graph menu: for small domains, clickDraw Operator Graph. (Optional: select optionfor whether to draw purposes of operators.) For the military domains, this will take some time,so either: clickBrowse Operator Graph, or selectSelected Operatorunder ”roots”, select anoperator (in ACP, useDevastate-networkor Add Dedicated Escort, then clickDraw OperatorGraph.
� Again click on nodes to expand, contract, or inspect them, after selecting the desired node-clickaction.
73
Chapter 7
Plan Execution and Replanning
SIPE–2 supports execution of a plan. During execution, the system accepts information about what
actions have been performed and what changes have occurred in the world. SIPE–2’s replanner responds
to unexpected events by revising the plan to respond to the current situation. While SIPE–2 does not
monitor the world directly, it accepts arbitrary descriptions of the world in its own language. In many
cases, it is able to retain most of the original plan by making some modifications, and is also capable of
shortening the original plan when serendipitous events occur.
In addition, SIPE–2 supports execution by an external software module, as described in Section 7.2.
The replanner can also be invoked without executing a plan. Section 3.7 describes the use of theAdd
Factscommand and thewhat-if function for invoking replanning during a what-if analysis.
7.1 Overview of Execution and Replanning
Figure 7.1 shows the various modules in the execution-monitoring system. The top two arrows show
the input to the execution monitor, and the unlabeled arrows below these two show which modules
call which others. The labeled arrows show the flow of data and information through the system as
it replans for an unexpected situation. These arrows are labeled with a description of the data being
passed. Examples and detailed module descriptions are given elsewhere [8], so only a brief summary is
given here.
During execution of a plan, some person or computer system monitoring the execution can specify
what actions have been performed and what changes have occurred in the domain being modeled. The
system changes its original world model permanently, so as to reflect the effects of actions already
performed. At any point during execution, the execution monitor accepts two types of information
about the domain: an arbitrary predicate, whose arguments are ground instances, that is now true, false,
or unknown; and a local variable name that is now unknown. SIPE–2 first checks whether the truth
74
Plan
JJJJJ
Unexpected Situation
��
���
ExecutionMonitor
��
���
plan andsituation
Planner� new plan
plan withunsolved goals
ProblemRecognizer
problems - Replanner�������
ReplanningActions
-
?
@@@@@R
��
���
Figure 7.1: Control and Data Flow in the Replanner
values for the new predicates differ from its expectations; if they do, it applies its deductive causal
theory to deduce more changed predicates.
Once the description of the unexpected situation has been accumulated, the execution monitor calls
theproblem recognizer, which returns a list of all the problems it detects in the plan. Thereplanner
is then given the list of problems found by the problem recognizer and tries certain replanning actions
in various cases, but will not always find a solution. The replanner changes the plan to look like an
unsolved problem to the standard planner in SIPE–2 (e.g., by inserting new goals). After the replanner
has dealt with all the problems that were found, the planner is called (the plan now includes unsolved
goals). The user can then select either automatic or interactive replanning, at which point the relevant
searches described in Chapter 3 are invoked.
If a successful modified plan is found, the Execution Monitor commences execution of the modified
plan at the point in time when the unexpected effects occurred. This modified plan should correctly
solve all the problems that were found. Unlike the planner, the replanner has not been used extensively
and may be less robust than the planner.
75
7.2 Execution and Replanning Profile
Figure 7.2: Profile for Execution and Replanning
TheExecutioncommand in the Profile menu brings up the menu in Figure 7.2. The first choice allows
execution to proceed without querying the user for unexpected occurrences after each action. (The code
that executes an action may still invoke replanning in this case.) The next option specifies how to get
information on unexpected occurrences. The default is to use menus that allow the user to enter predi-
cates using completion on predicate and object names. Another option is to enter predicate expressions
by typing them into the listener pane. The final option,use-variable, instructs SIPE–2 to use the value
of the variable*unexpected-predicates* as the list of predicates. This variable is set toNIL
after it is read, and will presumably be set again by some agent that is monitoring the world.
The second group of options affects the replanner. The first item allows replanning capabilities to
be used during the planning process, by having the planner accept changes in the world at the beginning
of each planning level. This option allows the planner and replanner to respond to the world during
the planning process. The second option allows specification of whether replanning should proceed in
movie mode, interactively, or automatically. The default is to ask the user before each replan.
Advanced Concepts:The rest of this section describes replanning profile options that only pro-
grammers are likely to use.
The third replanning option controls whether the replanner will attempt to reinstantiate a failed
precondition in order to apply the same operator with a different instantiation.
76
The fourth option instructs the replanner to produce a plan that is different from the original plan
(by preventing the application of the operator that originally inserted the failed action into the plan).
There are 3 allowable non-nil values for this option, as described in its corresponding variable below,
*prevent-same-solution* . This is useful when an action fails for some (probably unknown)
reason, so that all the preconditions of the original operator are still true. Producing the same plan in
such a situation could produce an infinite replan loop. On the other hand, preventing the same plan
causes the replanner to miss the plan repair when a different world would cause the same operator to
expand out differently and produce a correct solution. Domain-dependent knowledge about the nature
of the failure may indicate that the same operator will work after an initial failure. For example, a robot
arm that fails to pick up a nail from a non-empty hopper of nails should probably keep trying.
The fifth option specifies how to choose the goal at the root of the replan wedge, whenever the
replanner is replacing a wedge in the plan. Many values are allowed, as described in its corresponding
variable below,*select-replan-goal* . The replanner tried only one possible choice when it
removes a wedge from a plan, so the varied options allow other programs to intelligently direct the
replanning.
The last two replanning options apply toprocess nodes, which specify a single operator, when
the precondition of that operator is no longer true. These options control whether such aprocess node
will be replanned (i.e., its operator reapplied) or whether a higher-level goal will be replanned. Nodes
involving numericallevel predicates require special treatment (see Section 7.4), and are controlled
by the last replanning option. The next-to-last replanning option controls all other cases – if this option
is selected, such aprocess node will be replanned. This choice is desirable in domains where the
same operator would match with different instantiations, but replanning will fail otherwise. The default
is to prevent replanning of suchprocess nodes. Forprocess nodes that were introduced to solve
numericallevel predicates,No andYes select the same two behaviors as for non-Level nodes, but
there is an additional option,Delete , which is the default and will replace theprocess node with a
primitive no-op action whenever the node is being used to phantomize alevel predicate. Thelevel
phantom will become a goal, and its solution should achieve the effect of the deletedprocess node
(see Section 7.4).
The tracing choices in the final group of options are self-explanatory. Printing of the new plan
by the replanner is inhibited if any of these variables are T:auto-execute , auto-replan , or
inhibit-plan-printing .
SIPE–2 provides a capability for an external execution module to provide information to the ex-
ecution monitor. Setting*external-executor* to T causes sipe to write executed plans to
user::sipe-output and get unexpected predicates from the streamuser::sipe-request (or from
standard input if the value of*external-executor* is :simulate ). It is also necessary to set
*menu-for-unexpected* to use-variable to use an external execution module. See Sec-
tion 7.3 for more details.
77
Execution monitoring and replanning with no user interaction is useful for some domains, e.g., an
autonomous robot. The variablesauto-execute andauto-replan , described below, can select
this option. SIPE–2 normally refuses to execute plans with open nodes (e.g., unsolved goals). This can
be done by setting theauto-execute variable as described below.
The following variables can be used to select these options in an input file.
*menu-for-unexpected* [Variable]This variable chooses the method for accepting predicates for unexpected occurrences. Value isT (thedefault) for using menus with completion,NIL for accepting text in the listener pane, and:use-predicate for using the value of the variable*unexpected-predicates*.
*external-executor* [Variable]If T, write executed plans touser::sipe-output and get unexpected facts fromuser::sipe-request . If :simulate , get unexpected facts from standard input. If non-nil,*menu-for-unexpected* should be:use-predicate .
*select-replan-goal* [Variable]This variable specifies how to choose the replan wedge, whenever the replanner is replacing a wedgein the plan (generally to reachieve a failed EFFECT at the failed NODE.) A root with multipleapplicable operators is desired so the planner can get a different plan. This variable is always usedwhen NODE is of type Process or Executed. When NODE is of type Precondition, this variable is onlyused if the replanner has been invoked with a :revise message that has the argument:force-replan T — else a complicated algorithm for computing how to replan preconditions isused. The value can be a keyword (denoting an algorithm), a node, a predicate, or a function. Thesevaried options allow other programs to direct the replanning.
If the value is:lowest , the root is the first ancestor of NODE that has multiple operator choices. Ifthe value is:effect-higher , the root is an ancestor whose goal is EFFECT and with multipleoperator choices. If there is only one operator choice for EFFECT, then go up to the next higherancestor with multiple choices. If there is no such goal node for EFFECT, the replan will fail. If thevalue is:effect-any , the replanner first uses the algorithm for:effect-higher , and if no rootis found, the algorithm for:lowest if used (instead of failing).
If the value is a plan node or the name of a plan node, that node is used as the root. If the given node isnot an ancestor of failed NODE, then the:lowest algorithm is used. If the value is a predicate(either an ASCII expression or a predicate structure), the root is computed with the:effect-anyalgorithm, but with the given predicate for EFFECT. If the value is the name of a function of twoarguments, the root is the node returned by applying the function to NODE and the current plan object.
*prevent-same-solution* [Variable]If non-nil, the replanner does not allow the same operator to be applied to the goal that failed. Thedefault value isNIL . If the value is:replace , all non-executed nodes in the replan wedge areremoved from the plan when an action does not achieve its effects. If the value is:replace-all , allnodes (including executed nodes) in the replan wedge are removed. If the value is:reachieve , thereplanner will attempt to reachieve the goals (at the replan root) on the same objects, without deletingany nodes. Use:replace and:replace-all to force a repaired plan to be as different aspossible. A value ofT is equivalent to:replace .
78
auto-replan [Variable]If T, replan using automatic search with defaults without printing result,if :interactive , draw/print plan as directed byfast-interactive-search ,if :movie , replan in movie mode as directed byauto-interactive-search , andif NIL (the default), use menus to query the user.
auto-execute [Variable]If NIL (the default), do not execute partial plans and interact with user. IfT, do executions withoutasking user to choose nodes or see replanning result. If:opennode-ok , executegoal andnon-primitiveprocess nodes in plan.
*retry-processes* [Variable]This variable applies toprocess nodes not introduced bylevel goals. IfNIL , do not replanprocess nodes whose preconditions are false. IfT, replan them (hope for match with differentinstantiations).
*retry-level-processes* [Variable]This variable applies toprocess nodes that are introduced bylevel goals. Boolean values havethe same meaning as for*retry-processes* . If the value is:delete (the default), replace theprocess with a*removed-for-level* node whenever it is being used to phantomize alevelgoal.
perfectworld [Variable]If T, the Execution Monitor never pauses to accept unexpected occurrences, assuming that actions arealways executed perfectly. The default isNIL .
7.3 Executing a Plan
The execution monitor is invoked by clicking onExecutein the Plan menu. It executes each node in the
plan, flashing it if a drawing of the plan is on the screen. Upon execution of an action, the world model is
permanently changed to reflect the new situation and the user is allowed to input arbitrary predicates as
unexpected effects. Any drawn node is highlighted on the screen while unexpected effects are obtained
from the user or an execution module (as selected by the execution profile). Inhibiting user queries can
be accomplished either from the execution profile before planning, or during execution.
Whenever more than one action could be executed next, SIPE–2 allows the user to specify the order
of execution by displaying the menu in Figure 7.3. The user can choose a node to execute by clicking
on its name, execute all of them without getting this menu again, print a one-line version ofeach of
the nodes before choosing, reset theperfectworld flag, or suspend execution to use the GUI before
resuming. Executing a node changes its type: the next time the plan is reparsed, the node is drawn with
a different shape and color.
After all unexpected effects are entered for a node, the problem recognizer prints descriptions of
any problems that are found. If replanning is necessary, the user is given the choice of automatic or
79
Figure 7.3: Menu for Choosing Node to Execute
interactive planning, and the option of suspending to use the GUI to view the modified plan before
problem solving commences. The search algorithms described in Chapter 3 are then invoked. Upon
successful generation of a new plan, the user is given the option of displaying the plan and execution of
it is begun.
Advanced Concepts: This paragraph describes use of an external execution module. This
option must be selected as described in Section 7.2. This selection causes the function
execute.primitive , which is called by the execution monitor on each primitive action, to wait
for input to be read fromuser::sipe-request or standard input. The expression read is parsed
and used to set*unexpected-predicates* . The expression should either be the symbolquit
or a list whose car is the symbolexecuted , whose cadr is the name of the node just executed, and
whose cddr is a list of unexpected predicates.
unexecute &optional (ph lastplanhead) (plan *current-plan*) exceptions [Function]
This function can be used to return all executed nodes in a plan to their state before execution. Anynodes in the listexceptions are left unmodified. However, this does nor restore the initial worldmodel which has been destructively changed.
7.4 Replanning
Once problems have been found in the current plan, either because of a what-if analysis or because of
unexpected occurrences, the replanner is invoked. The replanner can also be told to replan a specific
node or a specific goal predicate. In addition, it can be told to force generation of a new plan by
replanning a given node differently, even when nothing has changed in the world. The latter is useful
when a plan fails for unknown reasons, or a human requests a different plan for some particular goal.
Replanning can proceed in movie mode, interactively, or automatically. SIPE–2 makes all actions
added/modified during replanning stand out in drawings. These actions have slightly thicker node icons,
and their labels are purple (the value of*replan-node-color* which should be set using theNode
80
ColorsandNode Shapescommands) instead of red. (For monochrome monitors, the label font is made
bold and larger). This property is reset on each call to the replanner, so that changes from the most
recent replan are the only ones highlighted.
Domain-dependent knowledge is necessary to take appropriate replanning actions. The SIPE–2
replanner makes its best guess at how to solve each problem before invoking the standard planner. If the
planner then fails, the original problem is solved again. Therefore, it is important to set the execution
and replanning profile appropriately for a given domain (see Section 7.2).
Advanced Concepts:The rest of this section is intended for programmers only.
Numericallevel predicates (see Chapter 18) require special treatment during replanning. It has
been common in SIPE–2’s domains of application to use numericallevel predicates recursively to
accumulate a certain quantity of some resource. This results in the general case of N actions that together
make thelevel goal true, i.e., the actionsphantomizethe goal. Thus, several actions that produce or
consume quantities will phantomize such a goal by being ordered before thelevel phantom. The
replanner, therefore, removes all such orderings to alevel phantom whenever one is removed, and
resets the phantom to a goal. This removal of orderings is correct since the goal relies on all these
orderings to become a phantom.
Another case requiring special treatment arises when the precondition of the operator of aprocess
node is no longer true. The replanner must decide whether such aprocess node should be replanned
(i.e., its operator reapplied) or whether a higher-level goal should be replanned. Replanning aprocess
node is desirable when the same operator would match with different instantiations. The default is to
not replanprocess nodes because replanning will fail if the precondition remains false. Ideally,
the replanner would like to test whether the precondition will fail. However, it will always fail until
some wedge is removed from the plan, and the replanner is, at this point, attempting to decide which
wedge to remove. SIPE–2 currently does not perform a search that involves removing wedges, checking
preconditions, and replacing wedges if the preconditions are still false. Therefore, it is necessary to
encode domain-dependent knowledge about this decision by setting the*retry-processes* and
*retry-level-processes* variables in the profile.
By default, the replanner applies a special algorithm to suchprocess nodes that were introduced to
solve numericallevel predicates.1 A process node that (1) was introduced to solve alevel pred-
icate, and (2) phantomizes alevel predicate, occurs whenever alevel predicate is being used recur-
sively to accumulate a certain quantity of some resource (see Section 18.5.2). When such aprocess
node has a precondition that is no longer true, the replanner replaces theprocess node with a prim-
itive no-op action. Thelevel phantom becomes a goal, and its solution should achieve the effect of
the deletedprocess node.
1This is controlled by the*retry-level-processes* variable.
81
This algorithm is justified as follows. Of the N actions achieving thelevel goal, some subset
M have their preconditions violated. All M cannot be kept in the plan, since one action may satisfy
the level that all M together satisfied before. Instead, SIPE–2 eliminates these M entirely, changes
the level phantom back to a goal, and solves it. The wedges of the subset M are replaced with
*removed-for-level* primitive actions, which record what happened, and ensure that the plan
structure remains valid at each level.
7.5 Intermingling Planning and Execution
As described in Section 3.8, SIPE–2 has the ability to interleave planning and execution. The operator
description language allows encoding of domain-specific information about which goals and actions can
have their planning delayed. Including the tokendelay in the description of a node in the plot of an
operator causes SIPE–2 to avoid planing any such goal or action until a plan suitable for execution has
been generated. Alternatively, the tokendelay-execute can be used to indicate that planning of a
node should be delayed until execution of that node. This allows expansion of a plan conditional on
information gathered earlier in the plan execution. When SIPE–2 attempts to execute such a node, the
planner is called. If it fails, the system fails execution; if the planner succeeds, then execution restarts
on the new plan.
The remainder of this section describes the delayed planning done for goals with thedelay token.
The planning of the delayed goals is started as a background job as soon as the original plan is ready for
execution. The original plan is used by the execution monitor until either an unexpected event happens
or a goal or action whose planning has been delayed is reached. In both cases, the plan produced by
the delayed planning process is retrieved (possibly waiting for the process to finish) and updated with
information about nodes that have already been executed. Execution proceeds on this updated plan while
another background job continues to plan any delayed goals in this new plan. When SIPE–2 attempts
to retrieve the results of the delayed planning process, it may notice that the delayed planning failed, in
which case the system tries again to solve the original problem in the current world state.
Note: The SIPE–2 planner has been used extensively in many domains, which has resulted in ro-
bustness and a finely tuned interface. The execution monitoring and replanning modules, however, have
not been used as extensively.
82
Chapter 8
Interacting with Other Systems
SIPE–2 can interact and cooperate with the following systems:1
� GKB-Editor — for graphically browsing and editing the sort hierarchy, and for browsing plandecomposition drawings.
� Act-Editor — for graphically displaying, editing, and inputting plans and operators.
� PRS-CL — for executing SIPE–2 plans, monitoring the world, and initiating replanning.
� Gister-CL — for uncertain reasoning to choose operators or resources.
� Cypress — for defining taskable, reactive agents.
� Tachyon — for temporal reasoning.
All of these systems except the GKB-Editor and Tachyon have Grasper-based GUIs, so the user can
switch among them by selecting them in the Application Menu. The GKB-Editor can be run on the
sort hierarchy through theModifycommand in the Domain menu, or by selecting a GKB-Editor browse
option when drawing a plan decomposition. The GKB-Editor runs in its own window, and must be
exited from a command in its APPLICATION menu before SIPE–2 can resume.
SIPE–2 has also been used as an agent in SRI’s Multiagent Planning Architecture, communicating
with other agents via KQML messages, as described in Section 1.2. In particular, it has cooperated
with Carnegie Mellon University’s OPIS scheduling system, and Orincon’s system for ship system
automation.
The GKB-Editor is distributed with SIPE–2 but is not loaded as part of SIPE–2. PRS-CL, Gister-CL,
and Cypress are not distributed with SIPE–2, but can be obtained from SRI under a separate license.
The following sections give more details about interacting with these systems. The use of Tachyon for
temporal reasoning is described in Section 18.6.
1SIPE–2, PRS-CL, GKB-Editor, Act-Editor, Gister-CL and Cypress are trademarks of SRI International.
83
8.1 The Act-Editor
In order to combine the capabilities of plan generation and reactive control systems, SRI has designed
a uniform representation for domain knowledge and plans. Our uniform representation refers to knowl-
edge provided by the user, e.g., plan fragments and operators, asActs. Acts are used by both the SIPE–2
planning system and the PRS-CL execution system. This allows both systems to cooperate on the same
problem, and allows software tools for graphically editing and creating Acts to enhance both systems
simultaneously and uniformly.
SRI has implemented the Act-Editor [11] for graphically displaying, editing, and inputting Acts.
For this reason, Acts are now the recommended method for encoding operators in SIPE–2. The Act-
Editor has its own manual [10], and SIPE–2 includes translators to and from the ACT formalism. A
user can input Acts graphically using the menu-based interface. A user can create or modify an Act by
selecting the appropriate actions from the menus; the Act-Editor prompts for all necessary information.
If a dictionary is defined (see Chapter 9), completion will be available when typing symbols. The
Act-Editor provides aVerify command to check the syntax and topology of an Act and to build up
dictionaries.
Appendix E describes briefly how an operator or plan in SIPE–2 is translated to ACT. This informa-
tion may be useful for an ACT user trying to understand SIPE–2 syntax or a SIPE–2 user trying to use
the Act-Editor.
8.1.1 Translation From ACT
There are-> SIPEcommands in the GRAPH and ACT menus of the Act-Editor, which translate sets
of Acts or individual Acts, respectively, into a valid SIPE–2 input file that conforms to the syntax
specifications provided in this manual. This file is saved to disk, but not loaded into SIPE–2. It must be
loaded in order to redefine operators.
8.1.2 ACT Translation Profile
Several variables control the translation process, and they can be set using theACT command in the
Profile menu, which brings up the menu in Figure 8.1. The second group of choices controls what
should be written to a file of Acts. The first few options specify whether Acts should be created for all
plan levels, for primitive actions and for unsolved problems. The fifth option causes SIPE–2 to save a
file of Acts immediately upon creation. The default is to create the file as a graph in Grasper but not
save it to disk. The sixth choice causes the Act-Editor to automatically create a dictionary for the new
file. The other choices are self-explanatory.
84
Figure 8.1: Profile for Act Translation
In the first group of choices in Figure 8.1, the second option enables the computation of the pre-
condition of a plan. This is an important capability, as all dependencies of the plan on the initial world,
including chains of deduced conditional effects, must be determined.
Advanced Concepts:This paragraph will be useful only to programmers. The first group of choices
in Figure 8.1 control translation of nodes within a plan. Choosing the node width can drastically change
the appearance of the generated Act. Several options permit certain nodes to be skipped during transla-
tion. These nodes are not necessary to the meaning of the plan for execution. However, all except the
planhead nodes are needed for replanning. The options for deduced effects and require-untils permit
certain slots within a node to be skipped during translation. These options should not generally be se-
lected, but are useful to an executor which can provide such knowledge itself in certain domains, e.g.,
when PRS-CL has Acts for deducing effects.
85
8.1.3 Translation to ACT with Dictionary Creation
There are two commands in the Domain menu for invoking translation to ACT. The-> ACT command
translates one or more operators, as selected by the user, and creates Acts as new spaces in the current
Grasper graph. The-> ACT allcommand provides full options for translation through a menu. Options
on the menu include selecting a subset of the operators, saving the file upon creation, automatically
creating a dictionary, and selecting the filenames for both the ACT and dictionary files.
Section 9.2 describes in more detail the use of-> ACT all to create a dictionary. The option for
creating a new dictionary should be used when an existing SIPE–2 domain is known to be correct;
otherwise, theVerifycommand in the Act-Editor should be used to interactively verify Acts and build a
dictionary.
There are three commands in the Plan menu for invoking translation of plans. The-> ACTcommand
in the Plan menu creates, without user interaction, an Act for the current plan (and possibly Acts for
primitive actions) in a new file, but does not save the file. The file name is “act-” prepended to the plan
name and “.graph” appended as the file type.
TheACT Optionscommand translates a plan with full options. The user can select the plan, the
file name, whether to save the file, and whether to set the ACT profile. Finally, the-> PRScommand
does the same translation as-> ACT and also loads the Act into PRS-CL when SRI’s Cypress system is
loaded.
8.2 The GKB-Editor
The GKB-Editor can be used to do the following:
� Create, edit, and browse a SIPE–2 sort hierarchy graphically, saving it out to a file that can beloaded into SIPE–2.
� Browse (but not edit or create) a plan decomposition drawing.
� Run a Web Server for anyone on the web to browse the sort hierarchy or a plan decompositiondrawing.
� Use the web server to save a presentation of a sequence of drawings.
The GKB-Editor is generic because it uses the OKBC protocol (Open Knowledge Base Connec-
tivity) for all knowledge-base interactions.2 SIPE–2 now supports OKBC for its sort hierarchy, thus
allowing use of the GKB-Editor. In theory, this also allows SIPE–2 sort hierarchies to be stored in any
2In earlier versions, it used the Generic Frame Protocol (GFP).
86
frame system supporting OKBC (e.g., LOOM and THEO). However, there is a substantial cost in effi-
ciency, so the distributed SIPE–2 system does not use OKBC internally. Any OKBC-conversant frame
system can access SIPE–2 hierarchies without knowing the internal representation.
The GKB-Editor isnot loaded when SIPE–2 is loaded. It can be loaded by evaluating(load-gkb)
after loading SIPE–2.
8.2.1 Creating and editing a Sort Hierarchy in GKB
The following steps can be used to create and/or edit a sort hierarchy KB in the GKB-Editor. Edits in
the GKB-Editor change both the GKB display and the SIPE–2 sort hierarchy that is in memory. When
the KB is saved, a file is written to disk that can later be input into SIPE–2.
� Invoke the GKB-Editor on the current sort hierarchy by clicking theModify command in theDomain menu. Then selectEdit sort hierarchy using the GKB-Editor and thesystem will create a KB for the sort hierarchy. To create a new sort hierarchy, do this withno domain defined. (The sort hierarchy always has some required classes that are used by thesystem.) The system may query the user for a KB name and filename and provides standarddefaults using the variable*domain-name* .
� In the GKB GUI, select Browse Class Hierarchy in the View Menu. (This switches the GUI fromdisplaying its previous drawing to drawing the KB just defined.) Click middle on a node to expandit, and click right for other options (such as contraction).
� (optional) Select Node Styles in the Preferences Menu to customize the drawings. For example,you can have selected attributes displayed with each node (although drawing takes longer).
� Use commands in the Frame Menu to create, destroy, and edit nodes. The List Frame Contentscommand will print all the attributes of a class/instance node in a pop-up window.
� To add attributes (slots) to nodes, select the Edit command in the Frame Menu. A Frame EditorGUI will appear. Its Slot and Value menus are used to edit slots and their values. In the Slotmenu, the Add Template Slot command is used to add a slot to a class, while the Add Own Slotcommand is used to add a slot to an instance.
� Use the Save or Save-as commands in the Knowledge Base menu to save the hierarchy to disk.Saving a sort hierarchy KB writes both .lisp and .sipe files of the sort hierarchy to disk. (Note: anytype component given for the filename is replaced.) The .sipe file is in SIPE–2 syntax and can beread into SIPE–2 to define the sort hierarchy. The .lisp file contains a list structure that compactlyrepresents the hierarchy. The .lisp file can be converted to a .sipe file (e.g., after editing it) withthe functionconvert .
The user can browse the sort hierarchy of an existing domain simply by loading the domain and
using theModifycommand. However, if changes are written to the KB file, then the input files for this
domain must be sure to load the same file that was written by the GKB-Editor.
87
8.2.2 Browsing a plan decomposition drawing
To browse a plan decomposition drawing, click on the Plan Decomposition command in the Drawing
menu, and choose one of the browse options. Such a drawing can be browsed in either SIPE–2 or the
GKB-Editor. Browsing in SIPE–2 allows all the standard options for what is displayed for each node.
Browsing in the GKB-Editor does not support SIPE–2 display options but does allows a Web server to
provide browsing capabilities to a user over the Web (and is implemented by creating a dummy KB with
pointers back to the actual plan nodes).
Note that any edits made will affect the drawing in GKB, but not the underlying plan in SIPE–2.
In the GKB GUI, click middle on a node to expand it, and click right for other options. The List
Frame Contents command in the Frame menu can be used to see more details of each plan node.
8.2.3 Running the GKB Web Server
Advanced concepts:This section is for programmers and should be skipped by those not intending to
use this capability.
To allow users to browse KBs (for either hierarchies or plans) over the Web, do the following:
� The GKB-Editor must be entered to create a KB for the current sort hierarchy. Use theModifyasdescribed earlier in this section.
� Quit the GKB GUI (from the Application Menu).
� Invoke (gkb-ed::http-kb-server) to start the server. This will print the URL for theport.
� Anyone on the web can go to this URL and use the GKB-Editor to browse this KB (this is singleuser – all users on this port will see the same drawing).
� To kill the server process, invoke(http:disable-http-service) .
8.2.4 Running the GKB-Editor directly
Advanced concepts:This section is for programmers and should be skipped by those not intending to
use this capability.
The GKB-Editor can be run on an existing KB without going through the SIPE–2 GUI (although
SIPE–2 must be loaded). This only works on an existing sort hierarchy, as new hierarchies must contain
the system classes. To do this:
� Start the GKB GUI with(user::gkb) .
88
� Select the Open KB command from the Knowledge-Base Menu.
� Select Connection: Local Connection.
� Select FRS type: SIPE.
� Select the SIPE–2 input file that defines the sort-hierarchy (e.g., sipe/input/blocks.sipe).
� Select the Browse Class Hierarchy command in the View Menu.
8.2.5 Programming Aids for the GKB-Editor
Advanced concepts:This section is for programmers and should be skipped by those not intending to
use this capability.
The file written by the GKB-Editor contains only the sort hierarchy, and contains the entire sort
hierarchy. This is not the same as the file that loads the entire domain, which should load the KB file as
well as other files (e.g., to define operators). In some existing applications, the sort hierarchy is defined
by multiple files. These can be loaded as normal, and will all become part of the GKB KB. When
the GKB-Editor saves the KB, the file written contains the complete hierarchy. The loading of all the
smaller files should then be replaced by loading the KB file.
The variable*gkb-kb* denotes the KB to be used when switching to the GKB-Editor. This
variable can be set in a SIPE–2 input file as described below (as long as the file is loaded after OKBC).
If *gkb-kb* is NIL when the GKB-Editor is invoked, SIPE–2 sets it by querying the user for a KB
name and filename (using standard defaults from the variable*domain-name* ) and then creates
and opens the*gkb-kb* before invoking the GKB-Editor. The SIPE–2 Resetcommand closes any
*gkb-kb* and marks it as not being in memory.
To set *gkb-kb* by creating a new KB, the following function can be used. If a call to
declare-sipe-kb is added to the domain input file, the GKB-Editor will be ready to edit/browse
the sort hierarchy whenever the domain is loaded.
*gkb-kb* [Variable]Value is the KGB object for the KB of the current sort hierarchy.
declare-sipe-kb name filename [Function]
This function creates a new KB in the GKB-Editor, and declares it as the current KB in SIPE–2. If theGKB-Editor with subsystem:sipe is not loaded, a message (describing why no KB was created) isprinted.Nameis any symbol and becomes the name of the new KB.Filename is a file where the thesort-hierarchy will be written if aSavecommand is issued in the GKB-Editor.
89
8.3 Cypress Systems
SIPE–2 and SRI’s reactive control system, PRS-CL, are capable of integrated planning and execution
with asynchronous replanning while running on different machines. In addition, SIPE–2 can use Gister-
CL’s evidential reasoning capabilities to choose parameters for operators, and to choose among opera-
tors. Both of these capabilities are present in SRI’s Cypress system. SIPE–2, Gister-CL, and PRS-CL
are component systems of Cypress.
In Cypress, PRS-CL executes plans generated by SIPE–2. When PRS-CL determines replanning
is necessary, a replanning request is sent to SIPE–2 while execution of the remaining branches of the
original plan continues without disruption. The planner returns a new plan which PRS-CL integrates with
its current activities. This two-way communication is supported by SIPE–2 in any of three protocols,
including:mpa which allows the planner and executor to run as separate agents on different machines
while using MPA messages to communicate. In MPA, the plan is stored in a third agent, the Act Plan
Server. The interactions between SIPE–2 and both PRS-CL and Gister-CL are described in the Cypress
manual.
CPEF (Continuous Planning and Execution Framework) is a successor of Cypress that provides
additional capabilities for continuously executing and modifying plans. CPEF is not yet documented
for use outside SRI.
90
Chapter 9
Dictionaries and Completion
The Act-Editor supports the creation ofdictionaries. A dictionary includes a sort-hierarchy and schemas
for functions and predicates that represent how many and what types of arguments they take. While this
knowledge is not necessary for doing planning, it is of great utility in knowledge acquisition, user
interaction, and verification.
These concerns become more important as domains become larger and more realistic. For example,
in recent SIPE–2 domains there are hundreds to thousands of objects, each with descriptive names of
a few dozen characters (e.g., cargo-pump2-richmond-480 and sf-bay-wildlife-refuge). There is a great
potential for misspelling and typing cramps.
SIPE–2 and the Act-Editor use dictionaries to provide completion to all names of a certain type
while interacting with either system. Typing the Space Bar completes the name if it is uniquely spec-
ified, or brings up a menu of all possible completions of the input so far. This is enormously useful
when acquiring new operators and during interaction with the system. SIPE–2 can provide completion
of individual names without a dictionary from its own sort hierarchy, but when entering predicates,
completion is much improved by defining a dictionary. Furthermore, the Act-Editor provides aVerifier
that can be used to verify that operators (in the form of Acts) use predicates and functions as specified
by the dictionaries in use.
SIPE–2 can automatically create a new dictionary when an existing SIPE–2 domain is known to be
correct. Alternatively, the Verifier in the Act-Editor can be used to build up a dictionary interactively.
Multiple dictionaries are permitted so, for example, there can be one dictionary about locations (shared
by several applications) and another for the domain-specific aspects of the problem. Multiple dictionar-
ies are ordered, and the Verifier searches them in the given order. The following sections describe the
use and creation of dictionaries within SIPE–2.
91
9.1 Dictionary and Verification Profile
To be general over many domains, there are several options for using and creating dictionary schemas.
The same predicate name can be used with different numbers of arguments (each different number of
arguments essentially defines a different predicate). Also, a schema specification for the arguments of a
predicate can be disjunctive.
Schemas are typically built by invoking the Act-Editor’s Verifier (after converting SIPE–2 operators
to Acts) and having it correct conflicts that are found between an Act and the existing dictionaries,
although SIPE–2 can automatically create a dictionary for an existing domain that is assumed correct
(see Section 9.2).
Figure 9.1: Dictionary Profile Menu
The Profile command in the Dictionary menu of the Act-Editor can be used to select the correct
options. It brings up the menu in Figure 9.1. The first option allows selection of one of the following
modes for running the Verifier:
� Log-only. Warning messages for all conflicts are printed to *terminal-io* (to allow editing inEmacs). Neither Acts nor dictionaries are modified. This supports making correction in an editor,e.g., doing string replacements in Emacs to process repeated misspellings.
� Auto-modify-dictionary. The dictionary is built automatically, assuming all Acts are correct.1
1There is no mode for changing Acts automatically because the intended spelling cannot be determined.
92
� Interactive. Through a series of menus, the user can change both Acts and/or dictionary schemasfor every conflict. This is the default mode.
Most of the other options in Figure 9.1 are self-explanatory. The second option applies only to the
Act-Editor, and the options regarding “external functions” apply to using external knowledge bases. The
printing options at the bottom should probably be disabled for an automatic dictionary creation (SIPE–2
does so during its automatic creation), since they can print a large volume of text.
The fourth option regarding “merging” needs more explanation. Building a predicate schema in the
Verifier involves extending it to cover a predicate instance in an Act that currently violates the schema.
Thus, the schema specifies one class, A, for some argument, while the predicate instance has an object
of another class, B, for that argument. The Verifier must merge these two classes. It provides the choice
of merging with a disjunctive schema (where the argument must be either A or B), or of keeping a single
nondisjunctive schema by using the common parent of A and B in the schema. Common-parent schemas
are the default and should be used when possible.2 The fourth option allows choosing whether two legal
classes for an argument should be merged by taking their common parent or creating a disjunction.
Some of these options should be chosen when the Verifier is being used for SIPE–2 Acts. In par-
ticular, the options for checking types of arguments and matching singular variables to plural classes
should be selected. (For example, if the variablelocation.1 is used, and the classLocation is not
in the dictionary, the system will then use the classLocations if it exists.) The following Act-Editor
function makes a whole set of customizations for
SIPE–2, including those just mentioned as well as common-parent merging:
clg::act-sipe-mode [Function]
This function sets several variables to customize the Act-Editor for SIPE–2. Environment slots aredisplayed as mousable buttons across the top of the graph pane. Typing with completion is used ratherthan menus when the list of choices is longer than 30. The Verifier is set to use common-parent merging,check argument types, and allow plural class names.
clg::full-menu-mode [Function]
This function enables several additional commands in the Dictionary menu of the Act-Editor. Thesecommands allow switching between verification and viewing of dictionaries without leaving the Dictio-nary menu. Note thatact-sipe-mode resets the menus to remove these additional commands.
For those who use only SIPE–2, a call toclg:::act-sipe-mode can be included in initializa-
tion files or files that load a domain.2While dictionaries and the Verifier support disjunctive schemas, disjuncts are not currently used when completing the
arguments of a predicate. For now, the system uses the first disjunctive schema during completion. Thus, if entering predi-cates with completion is desired, the default option of common-parent merging is best. Common-parent merging also makesdictionaries simpler and smaller.
93
9.2 Creating a Dictionary
The Act-Editor can be used to interactively create and modify dictionaries as described in its manual
[6]. Here, we describe SIPE–2’s abilities to automatically create dictionaries.
-> ACT all in the Domain menu can be used to create a dictionary. It does the following:
� Create a graph with the Act translations of all operators in it
� Create another graph and link it as the dictionary of the first graph
� Copy the sort hierarchy into the dictionary graph
� Run the Verifier on all Acts to automatically build up the dictionary.
The dictionary is not saved to disk by default, although this option can be selected in the-> ACT
all menu. The option for creating a new dictionary should be used when an existing SIPE–2 domain is
known to be correct. The dictionary has templates for all predicates and functions based on how they are
used in the operators. If there may be errors in the operators (e.g., misspellings), the Act-Editor can be
used to browse the dictionary to look for errors, and theVerifycommand in the Act-Editor can be used
to interactively verify Acts and incrementally build a dictionary. When a conflict is found in an Act,
the Verifier presents several options, which include changing the Act and/or the dictionary to extend its
schema or create a new schema.
The GKB-Editor can be used to create hierarchies for Act dictionaries. This is accomplished by
creating a SIPE–2 hierarchy in the GKB-Editor and using the-> ACT all command to translate the
hierarchy to an ACT dictionary.
9.3 Using a Dictionary in SIPE-2
To be used, dictionaries must be declared in the current graph. This allows different graphs to automati-
cally load their own dictionaries. This is done interactively with theDictionarycommand in the Profile
menu. This command brings up a menu with several options for manipulating the dictionaries on the
current graph.
The functionadd-sipe-dictionary adds a file or list of files as dictionaries in the current
graph. It is recommended that this function be called in the file that loads a domain, if there is a
dictionary for the domain. However,add-sipe-dictionary uses CLIM, so can only be called
after the GUI is started. When using this function, the user should be aware of the current graph before
loading a domain. However,add-sipe-dictionary makes some checks on the current graph
before changing it. If the graph contains a SIPE–2 drawing, or an Act, or has no spaces, or is the default
94
graph (sipe.graph in SIPE–2), then it adds the dictionary. Otherwise, it queries the user for confirmation
or a new graph. If the user aborts from this query, the filename is saved, and if the user clicks the
Dictionarycommand (e.g., after selecting another graph), the option of using the saved name is given
first.
add-sipe-dictionary filename &optional (load? t) (replace? t) [Function]
Adds filename as the current dictionary of current graph and loads it if it is not already loaded(unlessload? is NIL ). Filename can also be a list of filenames. Ifreplace? is T, any dic-tionaries already there are first removed. Unless the current graph is empty, contains Acts, containsSIPE–2 spaces, or is the default graph, the user is asked for confirmation or a different graph. Sets*use-act-dictionaries* to T. Must be called after CLIM is initialized.
*use-act-dictionaries* [Variable]If T, input completes with theSIPE–2 sort hierarchy for objects and ACT dictionaries for predicates. IfNIL , completion does not use ACT dictionaries. This variable is set toT whenadd-sipe-dictionary declares a dictionary.
The following variables allow declaration of a global dictionary for graphs with no declared dic-
tionary. Use of the latter is not recommended since it must be reset whenever the domain is changed.
However, it can be useful in two situations: (1) to specify a dictionary for files that are being generated
automatically (e.g., plans being generated and translated to Acts), and (2) to initialize dictionaries before
CLIM is running.
*sipe-dictionary* [Variable]The value can be a filename or a list of filenames. Setting this variable causes the Dictionary commandin the Profile menu to calladd-sipe-dictionary on the value when invoked. It also causes theReset command to reset the following variable when*sipe-dictionary* is on its list.
clg:*global-dictionaries* [Variable]A value ofnil is the default, which implies that graphs specify their dictionaries. This variable can beset to a list of graph names. The Act-Editor uses these dictionaries whenever it cannot find another.The user (or domain files) is responsible for resetting this global variable if Acts for another domainare loaded.
9.4 Completion
When querying the user for input about the domain, SIPE–2 uses pop-up windows that allow completion
of names being input. Hitting the Space Bar (or Tab key in CLIM 1) completes the name if it is uniquely
specified, or brings up a menu of all possible completions of the input so far. Completion has become
enormously useful as SIPE–2 domains have grown to several hundred objects, each with descriptive
names of a few dozen characters. Names for operators, predicates, objects, classes, and variables can
95
be completed, as well as entire predicates (predicate name and arguments). Completion works with or
without dictionaries, although it is more efficient and provides more value when a dictionary is used.
Completion is used when entering predicates, whether adding them to the execution monitor, adding
them to a what-if analysis, adding facts to the world, or drawing operator graphs. Dictionaries are of
particular value when entering predicates for two reasons. First, SIPE–2 uses the required class as a
prompt for each argument as shown in Figure 9.2, thus providing documentation and useful prompting.
(In addition, example legal arguments are given for new predicates.) Second, completion on argu-
ments is limited to those objects/variables of the correct type. Instead of each of the arguments to the
oil-pumped predicate ranging over all 500 known objects, the arguments range over 25 sea-sectors,
4 cargo-transfer-pumps, and 13 barges. In Figure 9.2, each item can be edited by a middle click, while a
left click clears the entry, allowing completion over every object of the correct class. (Hitting the Space
Bar after a left click displays a menu of all legal choices.) If an unknown predicate name is entered,
SIPE–2 will ask you to confirm it and enter the number of arguments for making a temporary dictionary
entry.
Figure 9.2: Entering a Predicate in the Oil-Spill Domain
SIPE–2 can provide completion of individual names for most planning structures without a dictio-
nary, by using its own sort hierarchy and other data structures. In fact, completion on object names
always uses the SIPE–2 sort hierarchy, since ACT dictionaries currently contain classes but not in-
stances. When the planner asks the user to make a choice (e.g., when choosing a resource, an operator,
or any planning structure to be drawn), it uses a menu for a small number of choices. However, when
the number of choices is larger than a given threshold, SIPE–2 uses typing with completion since CLIM
has problems with menus taller than the screen. The following variable holds the threshold and can be
set with theCompletioncommand in the Profile menu.
*select-with-completion* [Variable]SIPE–2 and the Act-Editor use typing with completion instead of menus when the number of choices isgreater than the value of this variable. The default is 30. A value of 0 causes these systems to alwaysuse typing with completion. If the value is any negative number, these systems always use menus.
96
The Completion command in the Profile menu also permits setting of the
*use-act-dictionaries* variable described earlier, as well as some variables that control
the Verifier.
There are some known CLIM bugs that affect completion. They are not difficult to work around, as
long as the user is aware of them:
1. After completing to a legal name, then typing to extend it to a new name, CLIM reverts back tothe completed name. To extend the name, simply backspace over its last character, type it again,and then continue typing.
2. After selecting a completion from a menu, it is sometimes necessary to press the return key to seeit.
3. When no completions are found, CLIM erases the input so far. It is necessary to reenter anysubstring that had been typed.
97
Chapter 10
Why Doesn’t SIPE-2 Work (Faster)?
This chapter has two sections, one describes recovering from stuck states when the system is not listen-
ing to you, and the other gives hints for debugging when SIPE–2 is not producing the desired plan.
One problem that fits neither of these categories occurs when SIPE–2 draws only part of a plan when
the plan is highly parallel or has many sequential actions. This happens because the virtual window
viewed in the graphics pane is too small vertically or horizontally, respectively, to draw the entire plan.
The virtual window can be enlarged using the WINDOW menu in Grasper. However, drawing can
become less efficient with a large virtual window.
Other more minor bugs are described in Appendix H, and CLIM bugs dealing with completion are
described in Chapter 9.
10.1 Recovering from Stuck States
The termstuck staterefers to the situation when the GUI apparently does not respond to input. This
section applies to only the CLIM implementation. Generally, the only stuck state on the Symbolics is
an error, which generally appear in the GUI Lisp listener with several reasonable continuation options
to select among.
Stuck states can arise for different reasons because of known CLIM bugs. Several remedies are
given below. CLIM does not update the GUI window until SIPE–2 returns to the CLIM command loop.
Thus the GUI will be unresponsive while SIPE–2 is computing. For example, suppose the user invokes
automatic problem solving (which may take several minutes) and then either closes the GUI window
or exposes another window on top of it. Upon reopening, the GUI window will be completely blank
with all displayed information gone and no indication that the GUI is active. Simply wait, and when
SIPE–2 returns to the CLIM command loop the screen will be refreshed and displayed information will
reappear. If planning is taking longer than expected, then the remedies below should be tried. If none of
98
them work, Unix commands can be used from another window to determine whether the SIPE–2 Lisp
process is still running. The remedies are these:
1. Try clicking right on the background. A common stuck state occurs when the GUI is in a loop
reading mouse clicks. Clicking right on the background exits such loops, and also recovers from
a stuck state described in 2, below.
2. Sometimes when the GUI should be in the command loop (e.g., after returning to the command
level from an error), it does not respond to mouse clicks. Let’s call this Stuck-state-1. Typing a
Return (or other input) restores CLIM. Unfortunately, if CLIM is not in Stuck-state-1, typing an
extraneous Return puts CLIM in Stuck-state-2.
3. CLIM enters Stuck-state-2 when an extra Return has been typed. In this state, the GUI Lisp
listener generally displays the message:
The input ‘‘’’ is not a complete Lisp Expression. Please edit your
input.
Doing a right mouse-click anywhere in the GUI restores CLIM from Stuck-state-2. Alternatively,
selecting any mouse-activated command in the command pane simultaneously initiates the
command and exits Stuck-state-2. A right mouse-click never gets CLIM stuck, so it is always a
good first attempt at recovery.
4. Another cause of stuck states is errors, which can be hard to recognize in CLIM. If an error occurs,
nothing will appear in the GUI. Any error message will be in the window from which the Lisp
process was first run. So if the GUI seems to have stopped, check the Lisp window for an error.
Errors generally include a continuation option to return to the SIPE–2 command level, and this
should generally be selected.1
5. If the GUI becomes hopelessly wedged, it is best to kill it and create a new one. Killing is done
by interrupting the Lisp process (type two controls-Cs to the Lisp window), aborting to the top
level, and calling the function(run-sipe) again. If even that fails, try meta-x panic.
1If any SIPE–2functions are called from the break in the Lisp window, their output will often still go to the CLIM windowand not to the Lisp window where the function is called. To get the output in the Lisp window,*sipe-output* must bebound to*debug-io* .
99
10.2 Debugging
This section contains suggestions for debugging an application that is not producing the desired plan.
First, hints for debugging specific modules have been included throughout this manual. Paragraphs
marked “important” discuss things that have caused problems in the past, so be sure to read these
paragraphs. Several appendices are useful for debugging. Appendix F lists the slots that are on plan
nodes and predicate nodes, describes functions that may be traced or broken, and describes what is in
each source file. All functions mentioned in this section are described in Appendix F.
SIPE–2 records the reason each failed operator did not apply. This is either the argument whose
constraints failed to match or the precondition predicate that was not true. These descriptions can been
seen by clicking on a node that has been expanded.
SIPE–2 makes it easy to get pointers to internal structures for debugging purposes. On Symbolics
machines, most text printed by SIPE–2 is mouse-sensitive so that underlying data structures can be
accessed by clicking on printed text. All nodes have an ID field which is the name of the node. This
name is a symbol that points to the node and can therefore be used to display the node. Operators,
objects, and classes have their names as IDs and nodes in plans have symbols generated as IDs.
The file debug.lisp contains functions that are useful for debugging. Some of these functions can
also be invoked through commands. There are functions to help in tracing and breaking functions.
Examples of other useful functions in this file include the following:
output-to-emacs [Function]
This function redirects the system’s standard output to whatever window was used to launch the Lispjob (usually Emacs or an xterm).
output-to-GUI [Function]
This function resets the system’s standard output to its normal setting in the GUI.
get-nodes node plan &key types fun . . . [Function]
This function returns a list of all nodes from the given node to the end of the plan that are of a type givenin the keywordtypes . If FUN is given, then that function is applied to all the nodes that are returned.
count-nodes node plan &key . . . [Function]
This function prints information about how many nodes of various types are in the given plan (afterNODE).
establishers predicate node plan &key . . . [Function]
This function returns a list of every node in the plan (after NODE) that establishes the given predicatein its effects.
100
collect-footprint node &key . . . [Function]
This function collects information about producers and consumers of conditions in the plan. The resultsare in*footprint* . The comments infootprint.lisp explain the many keyword options.
print-footprint &key footprint deduce-dependencies stream [Function]
This function prints a given footprint (default is*footprint* ) to a given stream (default is
*sipe-output* ) in an easily readable form.
Many commands in the Node menu are useful for debugging. For example, highlighting all the
nodes with a certain predicate in their effects may help find why a predicate is not true when expected.
Highlightingall the nodes mentioning a certain object may also be helpful. Using theAbstractcommand
in the Plan menu allows inspection of how the plan has developed level by level, which is useful both
for debugging and explanatory purposes.
When SIPE–2 does not produce the correct plan, it is up to the user to follow the planning, e.g., by
setting trace flags or planning interactively, to identify an undesired planning action. In a large domain,
it is best to plan nearly to the point of the undesired action and then start tracing or breaking functions.
For example, often a plan is not being generated because a specific operator is or is not being applied to
a specific node. A useful technique is to plan interactively until the planning level just before the suspect
operator application. Then, break the functionexpand-node which applies operators to nodes for the
operator (this can be done by selectingSet Optionsin the interactive search menu). When the correct
operator application is reached, low-level trace flags can be turned on before resuming execution, or the
functionmatchcond can be broken.
Preconditions (or other conditions) may fail to match because errors in the sort hierarchy prevent
the system from finding possible instantiations. The sort hierarchy can be drawn and inspected, or
the functionpossible-instantiations can be called to return the possible instantiations of a
variable. Another reason a condition may fail is that a node which should have a certain predicate in its
effects does not have it. Find the node that should make the condition true and print it. If the effects are
not as expected, tracing deductions during creation or copying of that node may help.
A plan cannot be traversed (e.g., to print or draw it) unless the context is right; otherwise, the system
will stop after the first choice node since no successor is present. If a plan seems to have disappeared,
determine whether the context is correct. TheList Nodescommand in the Domain menu lists all nodes
that are successors of a plan node no matter what their context. This can be useful in determining if the
problem is an incorrect context. Section 15.5 describes contexts in more detail. When SIPE–2 requests
a name for a plan, it ensures the corresponding plan object can be easily accessed — the symbol as the
plan name is bound to the plan object.
101
If a variable node is printed with a context ofNIL , all constraints in all contexts are printed. This
can sometimes be useful, but what is usually desired is the printed representation in one context, so the
correct plan object must be given as an argument.
10.3 Analyzing and Improving Performance
The planner’s performance can often be improved by an order of magnitude or more by correctly cus-
tomizing the planner for the given domain. This is described in Chapter 15.
In order to determine where SIPE–2 is spending its time, there are some variables than can be set to
gather timing information. These variables apply to major system functions that are most likely to cause
inefficiencies.
*time-deduce* [Variable]If T, causesSIPE–2 to print timing information when doing deductions.
*time-critics* [Variable]If T, causesSIPE–2 to print timing information when applying plan critics.
*time-pc* [Variable]If T, causesSIPE–2 to print timing information when matching an operator precondition.
*time-each-level* [Variable]If T, causesSIPE–2 to print timing information after expanding each planning level.
*Time-pc* allows further customization. If it is set to an integer, the system prints the timing
information only for operators that have more than that number of conjuncts in their precondition. If the
value of*Time-pc* is notNIL , notT, and not a number, then SIPE–2 prints timing information twice
for each precondition that is matched. The first match will use SIPE–2’s normal matching algorithm,
and the second match will ignore ordering links between actions that were originally unordered. This
second match may produce a different answer (which is ignored), but gives an indication of how such
ordering links affect performance.
By using these variables, the programmer can determine the source of inefficiencies. If deduc-
tions are slow, Chapter 17 provides important suggestions, such as using universal variables. A pa-
per available from SRI also describes efficiency issues in deduction for planning [7]. If matching
preconditions is slow, significant improvement can sometimes be achieved by reordering the con-
juncts of a precondition so that conjuncts which limit variable instantiations come first. Setting
*check-preconds-in-interp* and/or*check-precond-conflicts* to NIL also helps,
if this is appropriate for the domain (see Chapter 15). If application of plan critics is slow, setting
customizations controlling the critics can yield drastic improvements, as described in Chapter 15.
102
Some techniques other than setting customizations are important. Uninstantiated variables greatly
increase the computational complexity of planning, particularly if there are many possible instantiations.
The programmer can force instantiation of variables by specifying them in theinstantiate slot in
an operator definition. This is indicated when the instantiation choice that can be made at operator
application time is likely to be acceptably close to optimal. An example from one application shows
how important this can be. In a military domain,each operator that introduces a movement of troops
or cargo into the plan requires an immediate instantiation of the object being moved and its starting
location. The destination location remains as an uninstantiated variable — the planner can choose the
best destination as more constraints accumulate. This results in acceptable overall system performance
— plans with hundreds of actions/goals are produced in 1 to 3 minutes, with reasonable choices of
objects and locations. Without these forced instantiations, solution time would probably have been
measured in hours. SIPE–2can also backtrack on these forced instantiations if desired.
Declaring domain functions to beno-range-functions , as described in Chapter 12, can speed
up computations involving numerical variables whose constraints apply functions to uninstantiated vari-
ables. This option is indicated if computing the bounds on the possible value of the function is not
necessary for making correct planning decisions. In one domain with around 100 possible instantia-
tions for a variable and functions taking two such variables as arguments, declaring the functions as
no-range-functions reduced planning time by a factor of 3.
103
Chapter 11
Inputting the Domain
Advanced Concepts:the rest of this manual is for programmers only. (One exception is a user who
wishes to define problems different from those already defined by the programmer. That user should at
least read Chapter 14; references to intervening chapters may also be necessary.)
Any number of input files may be loaded without resetting SIPE–2. In large domains, the top-level
file generally just contains SIPE–2 customizations (see Chapter 15) followed by a series of s-expressions
to load files that accomplish the following, in the order given:
1. Defining the sort hierarchy
2. Defining the initial world predicates
3. Defining operators and applying them to define further predicates
4. Defining problems.
It is recommended that the problems be in their own file, so they can be loaded repeatedly to produce
different plans or to be redefined after garbage collecting all existing plans and problems.
Two variables can optionally be set in the domain to aid in generating good default filenames and
reloading problems:
*domain-name* [Variable]
Value is a symbol or string that names this domain. It is used in filenames so should not contain spaces.
*domain-problem-file* [Variable]
Value is a string for the filename that contains the problem definitions. This file will be load when the
Clear Plans command is given.
104
Important!: The problems must be definedafter the deductive rules have been defined and applied
to generate the initial deductions. When problems get defined,each gets its own copy of the world
predicates, so future additions will apply to only one of the problems.
By using the Act-Editor and the GKB-Editor, the programmer can now enter a new domain graphi-
cally without learning SIPE-2 syntax. The Act-Editor supports graphical editing of operators and plans.
The GKB-Editor supports graphical editing of the sort hierarchy. Both systems support saving the
edited structures to files written in valid SIPE–2 syntax. These systems are described in Chapter 8. The
GKB-Editor should be robust for entering a sort hierarchy, but the Act-Editor has not been used to input
SIPE–2 operators over the full range of possible constraints on variables.
The following variable should always be set toT when developing a new domain. It can be set back
to NIL when the domain is finished and parses correctly.
debug-domain [Variable]
If value isT (default isNIL ), the planner traces domain definitions and initial deductions, printing
warnings. Diagnosing parsing problems will be difficult unless this variable is T.
Input files are normally loaded by clicking on theInputcommand in the Domain menu. The follow-
ing functions can be called programmatically or from the lisp listener to load input files. On Symbolics
computers, the common-lispload function can be used to load any input file, but in other Lisps, one
of the following functions must be used.
lfile [Function]
Prompts the user for a filename and loads the given file usingload-and-update .
load-new-file filename [Function]
Loads the given file, but only if it has not already been loaded since SIPE–2 was reset. It also notesthe file as loaded by SIPE–2. For SIPE–2 to notice that a file is loaded, it must be loaded bylfile ,load-new-file ,load-and-update , or theInputcommand.
load-and-update filename [Function]
Always loads the given file and notes it as loaded by SIPE–2.
eval-load filename [Function]
This is the recommended function for loading SIPE–2 input files from a top-level input file. It is similarto the Common Lispload function, but some Common Lisp implementations switch the input streamfrom the file to the terminal when expressions read from the input stream are evaluated. This functionloads files without changing the input stream.
Here is an example of a typical top-level file for loading a domain:
105
(in-package :sipe);typical customizations to speed up planning(setq recheck-phan-deduce nil)(setq *check-preconds-in-interp* nil)
(eval-load "sipe:input;classes.sipe")(eval-load "sipe:input;preds.sipe")(eval-load "sipe:input;oprs.sipe")(init.deduce)(eval-load "sipe:input;probs.sipe")
Inputting the sort hierarchy and initial world predicates is described in Chapter 12. GKB-Editor
users can ignore the syntax in Section 12.2. Currently, the world predicates must still be input using
the SIPE–2 syntax. Inputting of operators and problems is described in Chapters 13 and 14. If the
ACT-Editor is being used, programmers can ignore those chapters. However, the syntax is still useful
for debugging the files written by these systems.
This chapter describes elements of the general syntax that apply to all input. All inputs to SIPE–2 are
in a language provided by the planner, the formal syntax of which is given in Backus-Naur Form (BNF)
in Appendix D, along with a description of how to read the BNF. The BNF is also spread throughout
the next several chapters. Example input domains are given in Appendices A, B, and C.
11.1 General Syntax, Punctuation, and Comments
Definition blocksare blocks that start with a keyword and end with the expressionend keyword. Exam-
ples of keywords that start definition blocks include:class object operator state-rule
causal-rule . In a SIPE–2 input file, any Lisp expression may be included anywhere except within
a definition block. Such expressions are evaluated during loading.
In SIPE–2’s language, colons (:) and semicolons (;) are always optional. Use them to make a file
more readable. We suggest putting colons aftereach slot name as in the examples in the appendices.
Any pair of a slot name followed by a slot value must be terminated either by a semicolon or an atom
that is asipe-input-keyword (this is a global variable the user can evaluate). Thus, semicolons
are optional in correct syntax, but may be used for stylistic reasons and better syntax-error detection.
For example, lists can have their elements separated by commas and the list ended by a semicolon.
Commas that separate list items are required for lists of atoms (e.g., variable names with constraints),
and optional for lists of lists (e.g., predicates).
The parser may not object to lists in certain slots but the planner may not do what is intended with
them. For example, if a goal node is given a list of predicates in itsgoals slot, the parser will not
complain, but the planner will achieve the first goal only.
106
Operator: Puton1Arguments: block1, object1 Is Not block1;Purpose: (On block1 object1);Properties: Authoring-System = SIPE-2, Class = Operator;Comment: “Great operator!!”;Plot:ParallelComment: “Split of champagne”;
Branch 1: Goals: (Clear object1);Branch 2: Goals: (Clear block1);Comment: “Rad goal”;
End ParallelComment: “Tasty Join node”;
ProcessAction: Puton.Primitive;Arguments: block1,object1;Effects: (On block1 object1);Comment: “very smooth action”;End Plot End Operator
Figure 11.1: SIPE-2 Syntax for Properties and Comments in Block-World Operator
In an input file, regular Lisp comments that start with semicolons (;) and go to the end of the
line are allowed anywhere Lisp expressions are allowed and anywhere that the semicolon is the first
nonwhitespace character on a line. Semicolons that are not the first nonwhitespace character will be
interpreted as part of the syntax.
11.2 Properties and Comments on Plans and Operators
Properties and comment slots can be specified for operators, plan nodes, problem nodes, sort
hierarchy nodes, and plot nodes. An example of the syntax for using these slots in an operator and its
plot is shown in Figure 11.1. The translators between the ACT formalism and SIPE–2 handle these
slots, except that ACT does not currently supportproperties on plot nodes, so they get dropped
going to ACT (comment slots remains however). In fact, the operator in Figure 11.1 was created in the
Act-Editor and translated to SIPE–2 syntax.
The plan-printing functions printproperties andcomment slots on all nodes when the full node
is being printed. The drawing functions draw theproperties andcomment slots of an operator as
their own nodes in the graph pane, but do not include these slots in plot node or sort-hierarchy drawings.
The user can always click left on such a node to see its full display, including these slots.
107
Depending on the intended use of comments and properties, the user may desire to have them appear
only in the operator, or to have them copied to plan nodes when the operator is applied, including
possibly copying them down from one level to another as the plan is expanded. When copying down
to new level, the comments and properties are copied to more detailed plans by copying them to the
purpose-node (i.e., the same node to which the effects of the higher-level node are copied). These
various options are controlled by the following variables.
*copy-comment-from-opr* [Variable]If this variable isT (the default), comments are copied from operator plots to the plan.
*copy-comment-down* [Variable]If this variable isT (the default), comments are copied down to future plan levels. This controlscopying when the plan node is copied down without being expanded.
*copy-comment-to-expansion-purpose* [Variable]This variable controls copying when a plan node is being expanded to the next plan level. If thisvariable isT (the default isNIL ), comments in the plan node being expanded are copied down to thepurpose-node. This option will refuse to overwrite a comment already on the purpose-node (copiedfrom the operator).
For properties, it has proven useful to have different behaviors for different properties. For the
following variables, the values can beT, NIL , or a list where the car isT or NIL which represents the
default value. The cdr of the list is the names of properties that are exceptions (i.e., are handled as if the
default value was negated).
*copy-properties-from-opr* [Variable]If this variable isT (the default), properties are copied from operator plots to the plan. Value can beT,NIL , or a list.
*copy-properties-down* [Variable]If this variable isT (the default), properties are copied down to future plan levels. This controlscopying when the plan node is copied down without being expanded. Value can beT, NIL , or a list.
*copy-properties-to-expansion-purpose* [Variable]This variable controls copying when a plan node is being expanded to the next plan level. If thisvariable isT (the default isNIL ), properties in the plan node being expanded are copied down to thepurpose-node. Value can beT, NIL , or a list. This option will append new properties to propertiesalready on the purpose-node, but refuse to overwrite a a specific property already on the purpose-node(copied from the operator).
SIPE–2 sometimes provides information onproperties slots. In particular, the replanner some-
times records its actions there, and the execution monitor records the type of node before execution. The
following variable can be set toT to provide data about operator applications:
*save-opr-arg-bindings* [Variable]If value isT (default isNIL ), the planner saves bindings of each operator’s arguments on theproperties slot of the node which the operator expanded.
108
11.3 Defining Primitive Actions
SIPE–2 considers anyprocess node whose action name does not correspond to an operator to be a
primitive node. It is also possible to specify certain goals as primitive nodes. Primitive goals would be
used when the plan is to be handed off to an execution system (such as PRS-CL) which can in turn solve
goals that are too low-level to be planned. The predicate name used in a goal determines whether the
goal is primitive or not. Goal predicates can be declared as primitive by using the following variable:
predicates-not-planned [Variable]The default value isnil . The vale can be a list of predicate names, in which case every goal with oneof these predicate names is considered a primitive node.
The above variable can be used to vary the level of detail to which the planner will plan (by speci-
fying different predicates as primitives). Thus, SIPE–2 is not limited to planning to a particular level of
detail that is hardwired into the operators.
11.4 The SIPE-2 Parser
As the parser reads input, it creates data structures to represent the entities described by the input. The
results can therefore be inspected by printing or drawing commands in the GUI. The following functions
invoke the parser:
define.domain [Function]
This function starts the parser for reading the sort hierarchy, operator definitions, and world predicates.The parser controls input until it sees the symbolstop at the top level (i.e., not within a definition).There may be any number ofdefine.domain commands, except that each file must have a beginningdefine.domain and a correspondingstop . Any input so surrounded may be in a separate file, butthe description of the sort hierarchy must be surrounded by adefine.domain and a correspondingstop , and must be loaded first.
define.problem [Function]
This function starts the parser for reading problem definitions. The parser controls input until itsees the symbolstop at the top level. Any number ofdefine.problem commands can beused. For large domains, it is recommended that problem definitions be in their own file, with*domain-problem-file* set to this filename.Define.problem can even be called interac-tively from a Lisp listener and the input typed to the system, provided that no colons or semicolons areused (SIPE–2’s readtable is not used).
The syntax for top-level declarations and definitions is
domain ::= (define.domain) domain.def� stop
problem.def ::= (define.problem) problem� stop
domain.def ::= operator.def� j sort.hier� j fpred-declsg predicates� j sexp�
109
11.5 Variables and Literals
Whenever the parser expects an argument, it can be given a variable name or a literal. Such arguments
are used in operators, deductive rules, problems, and predicates. The syntax is given in Chapter 13,
but summarized here. A literal can be the name of an instance, an arbitrary s-expression which is
represented as an instance of theExpr class, or a numerical instance (i.e., a number or list of numbers)
which is represented as an instance of theNumericalclass. An Expr matches only another Expr whose
s-expression isequal . By storing s-expression and numerical literals in the sort hierarchy, SIPE–2
permits variables such asexpr.1 andnumerical.1 to be used in an operator. They will match any
literal of the same class in a node to which the operator is being applied and thus allow the variable to
use the literal at various places in the operator.
When used inside a predicate, only the name of a variable or one of these literals can appear. When
used in other slots (e.g. the arguments slot of an operator), a variable name can be followed by a set of
constraints, described in Section 13.2. Literals cannot have constraints (SIPE–2 will issue a warning).
Normally, a SIPE–2 variable name is a class name followed by integers, or by a “.” and inte-
gers (seeop-variable-names? below). The variableverbatim-variable-names? can
be set toT to allow other names as described below. This is useful for descriptive names such as
destination-airport class airport instead ofairport.2 .
op-variable-names? [Variable]Variables are named by taking the class name of a class node in the hierarchy (deleting the S or ES ifit’s plural) and appending an integer. If the global variableop-variable-names? is T (thedefault), then a period is inserted between the class name. The period may already be in the input file,or the system will add it automatically when parsing the input. For example, if there is a classBLOCKS in the sort hierarchy, operators can speak about arbitrary blocks by saying block1, block7, orblock.12. This generates an indefinite node when the operator is applied. The indefinite noderepresents a planning variable with the constraint that it must be a member of the classblocks . Notethat individual blocks in the sort hierarchy must be named something other than block1, block.2, etc.
verbatim-variable-names? [Variable]If T, then if a variable name can be interpreted as a class name followed by integers (or a . andintegers), it will be, but if it cannot (either because of no trailing integer, or because the name beforethe integer is not a class name), then the name is accepted as is.
110
Chapter 12
Initial World State
The boxes on the left of Figure 12.1 depict the different representations used for encoding the initial
world state. The arrows show the origin of the information encoded in these representations. Static
properties do not change as actions planned by the system are performed (e.g., the size of a truck does
not change when it is driven). Domain objects and most of their static properties are represented by
nodes linked in asort hierarchy.
The sort hierarchy defines the classes and objects that exist in the domain and is composed of
class andobject nodes. Classes define sets, not individuals; i.e., the system will not use its class
structures as the instantiation of variables or as arguments to a predicate. Classes provide a mechanism
for distinguishing the types of individuals and for establishing default properties for whole sets of indi-
viduals. Thus, the links in the sort hierarchy should be interpreted as IS-A links, i.e., each individual
is an instance of each class of which it is a member. In particular, the hierarchy shouldnot be used to
represent part-subpart relations since the system would consider each subpart to be an instance of the
conglomerate part. Part-subpart relations should be expressed as predicates.
Static properties of domain objects that can be represented as unary or binary predicates should be
placed in the sort hierarchy. Properties must be represented as predicates if they change as actions are
performed.
Using a sort hierarchy permits SIPE–2 to incorporate the advantages of frame-based systems (pri-
marily inheritance, efficiency, and perspicuity), while retaining the power of the predicate calculus for
representing properties that do vary. Each object can have properties associated with it and can inherit
properties from classes in the hierarchy. Planning variables can be constrained such that possible in-
stantiations must have properties that satisfy given restrictions. Inputting the sort hierarchy is described
in Section 12.2.
For predications requiring more than two arguments and for all dynamic properties, a restricted form
of first-order predicate calculus is used. Dynamic properties are relationships that may change with the
111
SortHierarchy
StaticPredicateInstances
DynamicPredicateInstances
Rules
User
�
�
�
�
@@@I
���
Figure 12.1: Representing the Initial World State
performance of actions. This same calculus is, of course, used to describe goals, preconditions, and
effects in operators. Disjunction is not allowed in the world model.
Predicate names can be declared as static if all instances of that predicate do not change over time.
This allows the system to handle such predicates more efficiently since the effects of actions need not
be considered. The user need not specify all the predicate instances that describe the world. Instead,
rules similar to those used to specify the causal theory can be provided. The system will then use these
to deduce other predicates that must be true in the domain [8]. The syntax for these rules in described
in Chapter 13.
12.1 Sort Hierarchy Agent
As larger problems are addressed, the planner must use legacy databases rather than requiring all data
to be entered directly into the system. For this reason, we have begun making the SIPE–2 sort hierarchy
into an agent. This should allow SIPE–2 to access other databases and allow other agents to access any
SIPE–2 sort hierarchy.
We have developed a sort hierarchy API (application programmer’s interface) to provide modular
access to static knowledge about classes and objects for SIPE–2. The API consists of a small set of
functions (10) that provide the basic access operations required for planning, and are documented in
Appendix F.2. SIPE–2 can be readily adapted to operate using any underlying frame representation
system that provides appropriate definitions for this agent interface. The interface has been implemented
for the original SIPE–2 hierarchy subsystem.
To further facilitateaccess to alternative representation systems, an instantiation of a sort hierarchy
agent has been defined using the Generic Frame Protocol (GFP), jointly developed for DARPA at SRI
International and Stanford University, that provides a uniform interface model for frame-representation
112
systems. By using this agent, SIPE–2 can now be run with any frame representation system for which
GFP has been implemented (e.g., USC/ISI’s Loom, SRI’s SIPE–2 sort hierarchy, CMU’s Theo, Stan-
ford’s Ontolingua). A similar agent could easily be provide for OKBC. However, there is a substantial
cost in efficiency, so the distributed SIPE–2 system does not use OKBC or GFP internally.
12.2 Inputting the Sort Hierarchy
To use an external sort hierarchy agent, load whatever is necessary to make the API functions work.
However, an external hierarchy can slow down the planner by two orders of magnitude or more. The
remainder of this section describes how to create and use a sort hierarchy internal to SIPE–2.
The GKB-Editor is the recommended way to create and maintain a sort hierarchy. It can be used to
graphically browse, edit, and create a SIPE–2 sort hierarchy, without knowledge of the SIPE–2 syntax.
It will save the hierarchy to a file that can be loaded into SIPE–2. Instructions for loading and using
the GKB-Editor are given in Chapter 8. The GKB-Editor is invoked through theModify command in
the Domain menu. It edits the sort hierarchy currently in memory. Thus, the changes are effective
immediately.
The following keywords, variables, and functions are relevant to the sort hierarchy:
class [Keyword]object [Keyword]
SIPE–2 interns class and object names and makes them point to their corresponding internal struc-ture. Thus, one can inspect the value of these names to see their internal representations.Instanceand inst are synonyms forobject . Class nodes can have the following slots:subclasses ,instances , parent (or parent-class ), comment, andproperties . Object nodes mayhave only the latter three slots. The values ofproperties should be an a-list, while the value ofcomment can be any s-expression.
sort-hierarchy [Variable]SIPE–2 generates a root node which is pointed to by the global variablesort-hierarchy . Anyinput class that has no parent becomes a subclass of the root.
sipe-classes [Variable]This class is a subclass ofsort-hierarchy , and has as descendants all classes used by the system.In particular, all numerical classes and instances are descendants ofsipe-classes . To display thesort hierarchy without seeing theses classes and instances, theunlink-classes function can beused.
unlink-classes parent-class subclass [Function]
This function removes the link between two classes. This is useful for displaying the sort hierarchywithout seeing the system classes and instances. This is done by evaluating(unlink-classessort-hierarchy sipe-classes . This link can be permanently deleted as it is used only whendisplaying the sort hierarchy from its root.
113
link-classes parent-class subclass [Function]
This function restores the link removed by callingunlink-classes .
Before the release of the GKB-Editor, sort hierarchies were either input using SIPE–2 syntax, or
through a list structure that must be converted to SIPE–2 syntax with theconvert function described
below. To explicate the examples in the Appendices, an example of the syntax is shown below.1 A
formal specification of the syntax is given in Appendix D. In the current implementation, there should
not be overlapping subclasses and only one parent class is allowed. Any parent-class or subclass link
will link classes in both directions as long as both are defined (thus the user need specify only one side
of a parent/subclass link).
SIPE–2 input for part of a sort hierarchy describing food is as follows:
CLASS: VEGETABLEPARENT-CLASS: FOODSUBCLASSES: CHOKES, CORN, SPROUTS, MUSHROOMSEND CLASS
CLASS: CHOKESPARENT-CLASS: VEGETABLEPROPERTIES:
STEAM-TIME = 45;INSTANCES: CHOKEA, CHOKEBEND CLASS
OBJECT: CHOKEAPARENT-CLASS: CHOKESPROPERTIES:
COLOR = GREEN, SIZE = 5;END OBJECT
convert [Function]
This function converts a simple list structure of classes and objects into a SIPE–2 input file. It promptsfor an input filename of list structures and writes that file with a .sipe extension that is suitable for loadingdirectly into SIPE–2. The file will correctly define all objects and classes in the input list structure. Hereis an example of an expected input list structure with some values specified for thefoo property:
(class plant(foo baz)(class cellar
(object m-cellar (foo bar))(object l-cellar))
(class beer-tank(object bt-m1)(object bt-m3)))
1For creating files of SIPE-2 syntax, it is recommended that the user use the copying capabilities of an editor to copy aclass template and fill in the blanks correctly.
114
save-hierarchy [Function]
This function writes the current sort hierarchy out to a file on disk as a simple list structure of classesand objects suitable for input to the functionconvert .
12.3 Inputting Initial World Predicates
SIPE–2 reads a list of predicate instances and either places them in a newly created world or adds them
to an existing world. Before any predicate instances are defined, predicate names can be declared,
as described below, as either static or dynamic and as either open or closed. Since the declaration is
by predicate name, all instances of that predicate name will be declared identically. Every predicate
instance is either true, false, or unknown.
As depicted in Figure 12.1, the initial world predicates are divided into static and dynamic predi-
cates depending on whether any of their truth values change over time as actions are performed. The
system handles static predicates more efficiently since the effects of actions need not be considered in
determining their truth value. Predicate names are assumed dynamic unless declared otherwise.
Predicate names can also be divided by whether or not SIPE–2 uses theclosed-world assumption
in reasoning about them. Predicate names are assumed closed unless declared otherwise. This means
the system makes the closed-world assumption, assuming that if an unnegated predicate is not given in
the world model, then its negation is true. The advantage of a closed predicate is that the user does not
have to axiomatize the possibly enormous number of predicate instances that are not true in the domain.
A closed predicate instance withunknown as its truth value will be true only if such an instance is
explicitly listed in the world model.
For open predicates (i.e., the closed-world assumption is not used in reasoning about them), the
default truth value isunknown . Thus, an open predicate instance withunknown as its truth value will
be true if neither a negated nor an unnegated instance is present. A negated predicate instance of an open
predicate will not be true unless the negation is explicitly listed in the world model. The initial world
is a list of the unnegated and unknown closed-predicate instances and the unnegated and negated open-
predicate instances. All negated closed-predicate instances not matched by one of these are assumed
true. All unknown open-predicate instances not matched by one of these are assumed true.
The following example input defines predicate instances in a vegetable domain. Note that the two
negated predicates are unnecessary ifin is a closed-world predicate. They are identical and included
only to show the syntax:
predicates:(in choke-a refrigerator)(on choke-b table)-(in choke-b refrigerator)
115
(not (in choke-b refrigerator))(unknown (in choke-c refrigerator))end predicates
Figure 12.1 shows that world predicates can be provided directly by the user or be deduced by
deductive rules. These deductions must be initiated by calling the functioninit.deduce . Remember,
init.deduce must be called before the problems are defined. (This is described in more detail in
Chapter 13.)
init.deduce [Function]
This function applies deductive rules to the initial world. It must be called after the predicates and de-ductive rules have been defined, but before the problems have been defined. The call must be evaluated,so must be placed outside of a definition block.
The syntax for predicates is
domain ::= (define.domain) domain.def� stop
domain.def ::= operator.def� j sort.hier� j fpred-declsg predicates� j sexp�
pred-decls ::= [[ static-decl� j open-decl� j closed-decl� j function-decl� ]]
static-decl ::= static-predicates ( pred-name� )
open-decl ::= open-predicates [( pred-name� ) j t ]
closed-decl ::= closed-predicates ( pred-name� )
function-decl ::= no-range-functions ( fun-name� )
predicates ::= [[ predicates predlistend predicates j
additions predlistend additions j
initial-additions predlistend initial-additions ]]
predlist ::= predff, g predg f; g
pred ::= f- g( pred-namefpred-argg�) j (not ( pred-namefpred-argg�))
The meaning of the keywords relating to predicates is documented below:
predicates [Keyword]
This keyword indicates the predicates following it will be placed in a newly created world.
additions [Keyword]
This keyword indicates the predicates following it will be added to one specific existing world. Thisis useful for doing “what-if” analyses. The system queries the user about which world should have theadditions.
116
initial-additions [Keyword]
This keyword is used to change the common world for all problems that will be defined later. Thispermits multiple files to be used in defining an initial world.Additions is meant for changing oneparticular existing world that already has deductions done.Initial-Additions is used for initialworld predicates that are present in all problems and that have not yet had deductions done.
static-predicates [Keyword]
This keyword is followed by a list of predicate names and declares them as static. It should be insertedwithin the scope of adefine.domain before any predicates are defined. The following exampledeclaresadjacentandconnectto be static predicates:
STATIC-PREDICATES: (CONNECT ADJACENT)
open-predicates [Keyword]
This keyword is followed byt or a list of predicate names and declares them as open predicates. Itshould be inserted within the scope of adefine.domain before any predicates are defined. A valueof t makes all predicates default to be open, and closed predicates must then be declared as exceptions.
closed-predicates [Keyword]
This keyword is followed by a list of predicate names and declares them as closed predicates. It shouldbe inserted within the scope of adefine.domain before any predicates are defined. It is not neededunless anopen-predicates t declaration has been made.
no-range-functions [Keyword]
This keyword is followed by a list of function names and declares that they will not be computed untiltheir arguments are instantiated. In one domain with around 100 possible instantiations for a variable andfunctions taking two such variables as arguments, declaring the functions asno-range-functionsreduced planning time by a factor of 3.
117
Chapter 13
Operators
The Act-Editor is now the recommended method for encoding operators in SIPE–2, as described in
Chapter 8. Appendix E describes briefly how the syntax in this chapter corresponds to the ACT syntax.
There are four types of operators in SIPE–2: operator , state-rule , causal-rule and
init-operator . If an operator is defined asboth-operator then it becomes both an init-
operator and a state-rule. An operator has aplot that describes how to expand agoal or process
node to a lower level of detail. State rules, causal rules, and init operators are collectively referred to as
deductive rules, and have no plot. As with other SIPE–2 structures, the name of each operator evaluates
to the internal structure representing the operator. An example of the input syntax for an operator is
given in Figure 13.1.
Deductive rules are used only to add new effects by doing a deduction, and are discussed in detail
in Chapter 17. They do not have plots, but do have conditions as well as preconditions. The syntax for
an init-operator is exactly the same as for a state-rule. An example of the input syntax for a causal-rule
and a state-rule is given in Figure 13.2.
13.1 Slots on Operators
This section briefly describes the slots that can appear on an operator and gives the syntax for their
input. In this section,variablerefers to anything that can be an argument in an operator, i.e., a planning
variable, an object, or an s-expression. Operator arguments are described in Section 13.2, and their
internal representation is described in Section 13.3.
The value of a slot can be accessed by calling the slot name as a function with the operator structure
being the first and only argument. For example,(arguments puton1) returns the list of internal
structures that represent the arguments of the operator namedputon1. The id , type , properties ,
andcomment slots are present on every internal structure and are filled in automatically by the system.
118
Operator: Puton1Arguments: block1, object1 Is Not block1;Purpose: (On block1 object1);Plot:Parallel
Branch 1: Goals: (Clear object1);Branch 2: Goals: (Clear block1);
End Parallel
ProcessAction: Puton.Primitive;Arguments: block1,object1;Resources:block1;Effects: (On block1 object1);End Plot End Operator
Figure 13.1: SIPE-2 Input for Puton1 Block-World Operator
Causal-Rule:Not-OnArguments: object1,object2,object3;Trigger: (On object1 object2);Precondition: (On object1 object3);Effects: :(On object1 object3);End Causal-Rule
State-Rule: Deduce-clearArguments: object5,object6, object4 Class Existential;Trigger: :(On object5 object6);Condition: :(On object4 object6);Effects: (Clear object6);End State-Rule
Figure 13.2: SIPE-2 Input for Block-World Deductive Rules
119
A limited form of disjunction may be used in several slots.Precondition , condition ,
purpose , andtrigger slots of operators can have (OR pred1 pred2 . . . predN) wherever they
expect a predicate, but the semantics are that predicates from the OR are tried only until a match is
found. In other words, if pred1 has some possible matches, they are the only matches that will ever be
considered.
id operator [Function]
This is the name of the node. The name is a Lisp pointer to the node.
type operator [Function]
The type of the operator is stored here (e.g., operator, state-rule).
arguments operator [Function]
This slot is used to declare variables and constraints, and to match the operator to a plan node. Its valueis a list of variables. Recommended style is to list all variables mentioned in the operator in this slot.
resources operator [Function]
This slot is a list of variables, generally a subset ofarguments . It implements the notion of reusableresource as the system assures that any resource will not be used by another action in parallel. Resourcescan also be declared for particular actions inside the plot, which is generally more useful.
instantiate operator [Function]
This slot is a list of variables, generally a subset ofarguments . These variables are instantiated by thesystem immediately after the operator is applied (the user can make the choices — see Section 15.1).The instantiation is done after the preconditions are matched and after the plot is inserted into the plan,but before any deductions are made. This is useful for computing certain numerical quantities and forencoding domain knowledge about when various variables should be instantiated.
precondition operator [Function]
This slot is a list of predicates. In deductive rules, it is the antecedent of a deduction. In regular operators,the precondition must be satisfied before the operator can be applied. Preconditions are goals the plannerwants to be true but will not try to make true. If you want the planner to make them true, put them asgoals in the plot of the operator. This provides added flexibility, since it is common that one wants toapply an operator if a certain situation exists, but does not want to achieve that situation if it does notexist. Satisfying a precondition (for any type of operator) generally constrains the variables that arearguments of the precondtion. If X is a variable in P, a precondition, only instantiations of X for whichP is true will be considered hereafter (i.e.,x jP(x)). During matching of such a precondition, the systemgenerates constraints enabling the variable to match all and only those objects for which the preconditionis true. For an advanced discussion of the semantics of preconditions, see the description of the variables*check-preconds-in-interp* and*check-precond-conflicts* in Chapter 15.
120
condition operator [Function]
This slot is a list of predicates, and is present only on deductive rules. In deductive rules, both conditionsand preconditions are the antecedents of deductions but are matched under different circumstances (seeChapter 17).
purpose operator [Function]
This slot is a list of predicates, and is present only on regular operators. It describes what the operator istrying to accomplish and is used to determine to which goals this operator is applicable. It is also usedto determine where in the plot the purpose is accomplished.
effects operator [Function]
This slot is a list of predicates, and is present only on deductive rules. It represents the conclusions of adeduction.
trigger operator [Function]
This slot is a predicate, and is present only on deductive rules. It triggers the application of the operatorwhen it is matched by new effect.
properties operator [Function]
This slot is a list of properties. This slot is not currently used by the system.
comment operator [Function]
This slot is a comment for documentation purposes.
time-constraints operator [Function]
This slot is a list of the temporal constraints on the nodes in the plot of this operator. Each constraintconsists of one of the thirteen Allen constraints and the two nodes to which this constraint applies. Thesyntax refers to the nodes by the names of their goals or action, and also permits numerical intervals aspart of the constraint (see Section 18.6).
plot operator [Function]
This slot may appear only on regular operators. It is instructions for expanding a node to the next level.If variables in the plot do not occur in the arguments of the operator, they are automatically added to thearguments of the operator, but a warning message is printed out in case one of them is misspelled. Plotsare described in detail in Chapter 14.
121
The syntax for operators is
operator.def ::= [real-opj rule j causal-rule]
real-op ::= operator op-namef;g args[[ resourcesj instantiatej purposej
preconditionj t-constr-slotj prop-com]] fplotg end operatorrule ::= rule-typeop-namef;g args[[ triggerj effectsj conditionj
prop-com]] end rule-typecausal-rule ::= causal-rule op-namef;g args
[[ triggerj effectsj conditionj preconditionj prop-com]]
end causal-rulerule-type ::= [state-rule j init-operator j init.operator j both.operator ]
trigger ::= trigger predf; g
purpose ::= purpose predf; g
precondition ::= [precondition j preconditions ] predlist
condition ::= condition predlist
effects ::= effects predlist
t-constr-slot ::= constraints: ftconstraintg� f; g
predlist ::= predff, g predg f; g
pred ::= f- g( pred-namefpred-argg�) j (not ( pred-namefpred-argg�))
tconstraint ::= ( allen node node) j
( qual-relation( point node) ( point node))
allen ::= starts j overlaps j before j meets j during j
finish j finishes j equals
qual-relation ::= later j later-eq j earlier j earlier-eq j equals
point ::= start j end
node ::= ( node-namef . integerg)
node-name ::= op-namej pred-name
prop-com ::= [[ propertiesj comment]]
properties ::= properties prop.decf, prop.decg� f; g
prop.dec ::= prop-name= sexp
comment ::= comment sexp
122
13.2 Operator Arguments and Constraints
The programmer can define local variables in operators and problems using thearguments ,
resources , or instantiate slots or implicitly by reference to it in the plot. Recommended style
for operators is to define arguments using thearguments slot; if the user defines a named argument
implicitly or within a plot, SIPE–2 prints a warning. The warning helps detect misspelled argument
names. Because constraints do not vary with time, SIPE–2 generates the same internal representation
whether constraints are defined in thearguments of the operator or in the plot.
Variables in operators are named, constrained, and bound through thearguments slot of the op-
erator which determines how the operator is matched to a node. Individual plot nodes can have an
arguments slot as well as aresources slot. If a variable is listed as a resource (it should also
be declared as an argument), the system assures the same object will not be used by another action in
parallel. This implements the idea of a reusable resource; in fact, there are two variations of reusable
resource as described in Chapter 15. Chapter 18 describes the implementations of consumable and
temporal resources.
IMPORTANT! When matching operators to nodes, operators bind their arguments by matching
thearguments slot of the operator to thearguments slot of the node. Forprocess nodes, this is
the obvious algorithm. For agoal node to match according to its goal predicate, any explicit arguments
given for the node must be in the same order as the arguments of itsgoals predicate. (If arguments are
not given, they default to the arguments of the goal predicate.) Similarly, the arguments of an operator
should be in the same order as the arguments of itspurpose predicate. If SIPE–2 parses an operator
whose arguments do not match its purpose, it prints a warning and reorder the arguments of the operator
to match the purpose. This reordering can be prevented by setting the following variable:
*leave-opr-args* [Variable]If T, never reorder an operator’s arguments to match the operator’s purpose. The default isNIL , asnot following this convention can lead to confusing behavior.
The permitted variable names and literals are described in Section 11.5. Constraints can be ap-
pended to variable names in thearguments andresources slots. The constraints permitted are
documented in the BNF below. Here are more readable examples:
CLASS EXISTENTIALCLASS UNIVERSALCLASS <any defined class>OF TYPE <any defined class>IS NOT <any defined instance>IS NOT <any local variable name>IS NOT (<any instance> <any instance> ...)IS NOT OF TYPE <any defined class>
123
WITH <any attribute name> <any attribute value>WITH <any attribute name> EQUAL TO <any attribute value>WITH <any attribute name> NOT-EQUAL TO <any attribute value>WITH <any attribute name> GREATER THAN <any numerical value>WITH <any attribute name> LESS THAN <any numerical value>WITH <any attribute name> =GREATER THAN <any numerical value>WITH <any attribute name> =LESS THAN <any numerical value>SAME AS <any previous variable>IS <numerical object>IS <numerical function call>IS (EXPR <value>)IS [ <numerical object> <numerical object> ]IS CURRENT VALUE OF <continuous-variable>IS PREVIOUS VALUE OF <continuous-variable>
Most of these are self-explanatory. The first two are discussed in Chapter 17. For allWith con-
structs, the value can be either a literal value (a number for the numerical values) or the name of a
variable that is an argument to the operator, as long as that variable is instantiated when theWith con-
struct is evaluated. Note thatequal to andnot equal to can take non-numerical values. There
is a possible ambiguity — any symbol in the value spot that can be interpreted as an argument to the op-
erator will be (instead of being interpreted as a value). The firstWith construct (WITH attribute
value ) is like theequal to construct except the value is left intact and never interpreted as the name
of an argument.
The syntax for variables, arguments, and constraints is
args ::= arguments arg.deff, arg.defg� f; g
resources ::= resources arg.deff, arg.defg� f; g
sresources ::= [sresources j sharedresources ] arg.deff, arg.defg� f; g
instantiate ::= instantiate arg.deff, arg.defg� f; g
pred-arg ::= [literal-argj arg-name]
arg.def ::= [literal-argj named-arg]
literal-arg ::= [object-namej expr-formj numericalj functionj range]
expr-form ::= (expr sexp)
numerical ::= numberj ( number�)
function ::= ( symbol[numericalj symbol]�)
range ::= [ numericalf, g numerical]
named-arg ::= arg-namefconstraintg�
constraint ::= class-conj quant-conj is-conj with-conj with-eqj same-con
class-con ::= [of type j class ] class-name
124
quant-con ::= class [existential j universal ]
is-con ::= is [is-not j is-currentj numericalj expr-formj function
j rangej object-name]is-not ::= not [[of type class-name] j object-namej ( object-name�) j arg-name]
is-current ::= [current j previous ] value of arg-name
with-eq ::= with prop-namefequal to g [numericalj arg-namej sexp]
with-con ::= with prop-name[greater j =greater j less j =less ] than [nu-
mericalj arg-name]same-con ::= same fasg arg-name
13.3 Variable Descriptions and Variable Pointers
Programmers often find it helpful to look at the internal representation of arguments (i.e., variables
or literals). A variable in an operator or plot is represented as avardes(for variable description). A
vardes is a list of at least three elements that describes to the system how to create an actual SIPE–2
planning variable, including the initial constraints to put on the variable at time of creation. The car of
each vardes is its name, the second element is one of(constraint instn expr ) which specifies
which type of literal it is, and the third element begins a list of constraints in theconstraint case
or is the structure representing the instance (object) or expr in the other cases. For example, evaluating
(arguments puton1) in the blocks world (theputon1operator is shown in Figure 13.1), produces
the following printed representation of the vardeses in the arguments slot:
((BLOCK.1 CONSTRAINT (CLASS <CLASS BLOCKS>) (NOT-SAME (OBJECT.1)))(OBJECT.1 CONSTRAINT (CLASS <CLASS OBJECTS>) (NOT-SAME (BLOCK.1))))
All arguments in a plan arevarptrs(for variable pointers), which are planning variables created from
vardeses. Figure 5.4 shows the printed representation of a varptr in the mobile robot domain. A varptr
is a dotted pair, where the car is the name of the variable and the cdr is a pointer to an internal structure.
The type slot of this structure is one of(indef instance expr) . A structure of typeindef
(for indefinite) represents a planning variable, aninstance is an object from the sort hierarchy, and
anexpr is an Expr. Anindef structure stores constraints that accumulate during planning, indexing
them by context. Thechoice-nodes slot of an indef structure stores an a-list that associates
further indef structures with choice points that are elements of the context (see Chapter 15). The
indef structures on the a-list contain the actual constraints in theirproperties slot.
When an operator is applied to a node in a plan, the vardeses in the operator are matched to the
varptrs in the node. If the match is successful, then the constraints from the vardeses are added to the
varptrs, indexed under the choice of applying this operator to this node. The operator often has more
125
arguments than are matched, which causes new varptrs to be created from these additional vardeses.
Appendix F describes functions that inspect and operate on varptrs and vardeses.
126
Chapter 14
Plots and Problems
The Act-Editor is now the recommended method for encoding plots and problems. Appendix E de-
scribes briefly how the syntax in this chapter corresponds to the ACT syntax.
A plot is the part of an operator that specifies how to expand a node to the next level of detail. A
plot consists of a network of goals and actions. Thus, a problem is simply a plot without the rest of
the operator — it can be one goal or a whole network. In this chapter,variablerefers to anything that
can be an argument in an operator, i.e., a planning variable, an object, or an s-expression. Variables are
represented internally as a vardes in the plot of an operator and as a varptr in a problem.
Primarily, plots consist of the following types of nodes:
1. goal process choiceprocess
2. cond condpattern endcond
3. split join
Nodes in Groups 2 and 3 specify control information to encode the graph structure of the plot.
Group 1 nodes specify the actual actions and goals in a plot. The slots on these nodes are doc-
umented in Appendix F.3. The slots the user might specify for a Group 1 node in an operator
arearguments , resources , effects , delay , delay-execute , external-condition ,
protect-until , duration , start-time , andstop-time . In addition,goal nodes would
specify agoals slot, andchoiceprocess andprocess nodes anaction slot. There is also
a loop facility — aprocess node whoseaction is generate-goalsmust have apattern slot, as
described in Section 14.3.
An example of the SIPE–2 input for a plot was given in Figure 13.1. Conditional plans can be
specified in a plot as in Figure 14.1.Cond andendcond nodes are similar tosplit andjoin nodes.
127
Plot:Cond
Condpattern 1: (holding robot1 object1)Goal: (holding robot1 object1)
Condpattern 2: (not (holding robot1 object1))Goal: (inroom robot1 room1)Goal: (holding robot1 object1)Delay
End cond
Figure 14.1: SIPE-2 Input for a Conditional Plot
The various branches of the conditional should get the world back to the same state when theendcond
is reached. Thecondpattern nodes are used as in a Lisp cond; the first one that matches is executed.
In addition to specifying a network, the plot can be the single atomcopy which directs the system
to copy the previous node instead of expanding it. This allows the programmer to control the abstraction
level at which SIPE–2 expands a goal. The programmer needs to use the preconditions and constraints
to eventually terminate the match to the copying operator.
branch number [Keyword]
condpattern number [Keyword]
These are used to declare the beginning of a new branch after either a split or cond node. Both of theseare followed by a number that SIPE–2 ignores. The number could be anything; there is no need tonumber the branches in any particular order.
copy [Keyword]
Copy directs the system to copy the previous node instead of expanding it.Copy should be the onlystep in the plot since SIPE–2 ignores anything following it.
14.1 Defining Problems
A problem is a plot that occurs without the rest of the operator, with two minor differences. First,
a problem is surrounded byproblem: nameandend problem instead ofplot andend plot .
Second, problems occur after a call to the function(define.problem) and before its corresponding
stop instead of after a call to(define.domain) .
Plots and problems can contain constraints on variables listed as arguments to plot nodes, as de-
scribed in Section 13.2. However, this is generally only used in problems, as operators specify their
constraints in thearguments slot. The ability to use constraints in the problem specification allows a
wide variety of problems to be expressed. The name of each problem points to the planhead node for
128
(define.problem)Problem: pam-to-idyllwild
Goal: (visit pam idyllwild)End problem
Problem: colored-stackParallel:
Branch 1: Goal: (on a c)Branch 2: Goal:
Arguments: blueblock2, redblock2 is not r1;Goals: (on blueblock2 redblock2)
End parallel End Problem;; this problem gets block A on block C at the same time that;; some blue block is on some red block other than R1.Stop
Figure 14.2: SIPE-2 Input for Two Problems
that problem. Each plot node also has a name that is stored in itsid slot. Figure 14.2 shows a valid
input file that defines two problems.
The following function creates problems programmatically and is useful for passing in problems
from remote clients or other systems. Alternatively, Acts can be used to specify problems.
make-problem name plotform &optional world [Function]
Creates a problem with given name, plot, and world. The world defaults to the first member of thelist worlds . The plot form is a list structure version of the SIPE–2 syntax, with no punctuation, thelabels afterend omitted, and a list aroundeach predicate and around eachparallel andcond group.There must be anend for eachparallel andcond group and the end of the problem.
Here are two example calls tomake-problem :
(make-problem ’prob21 ’(goal (protected coa-1) end))(make-problem ’prob22 ’((parallel branch 1 goal (protected coa-1)
branch 2 goal (protected coa-2)end) end)))
129
14.2 Plot Slots
In this section, the keyword entries document the inputting of a slot, and the function entries document
the accessor functions for the slots.
effects condition [Keyword]
effects node [Function]
This slot is a condition (a list of predicates) that represents the context-independent effects the actionhas on the world. Context-dependent effects are then deduced from these given effects by the deductiverules.
delay boolean [Keyword]
delay-execute boolean [Keyword]
delayp node [Function]
This slot isT, NIL (the default), ordelay-execute . It becomesT if the user specifies the symboldelay as a slot name with no punctuation, as in Figure 14.1. The functiondelayp accesses this slot.A delay slot marks the node as one whose planning can be delayed until execution has commenced(e.g., in the plot for the conditional plan, planning of the holding goal in the second branch will bedelayed until the robot is executing the plan it has produced for other goals). Alternatively, the tokenDelay-execute can be used to indicate that planning of a node should be delayed until execution ofthat node. This provides a way to intermingle planning and execution in a given domain.
external-condition boolean [Keyword]
external-condition node [Function]
This slot is a boolean which becomesT if the user simply specifies the symbolexternal-condition as a slot name with no punctuation. It applies only to goal nodes andindicates that the goal is not to be achieved by planning actions, but rather will be achieved by apossibly parallel action and phantomized by an ordering link. This is useful for coordinating actions onparallel branches and is described in Chapter 16.
protect-until condition [Keyword]
purpose node [Function]
This slot provides specification of the plan rationale and helps the execution monitor discover problemsduring execution. The functionpurpose accesses the slot input as protect-until. SIPE–2 ensures thatthe main effect of the action remains true until the condition holds. The condition may be either apredicate list or the atompurpose . The latter indicates that the main effect must be true until itscontaining operator’s purpose comes true. If the containing operator was applied at the top level of theproblem, then the main effects must be true at the end of the plan.
130
start-time numerical [Keyword]stop-time numerical [Keyword]duration numerical [Keyword]
These slots take one planning variable as their value. The variable should be an argument of the currentoperator with appropriate constraints to be interpreted as a time. In particular, it must be a numericalvariable. SIPE–2 then translates these slots into effects of the same plot node, as described in Section18.6.
action action-names [Keyword]action node [Function]
This slot must be a single action name on aprocess node and a list of action names on achoiceprocess node. The system adds information to this slot when the node is expanded. Thisinformation gives, for each operator, an expansion or a reason for failure.
goals predicate [Keyword]goals node [Function]
There is a short syntax for goal nodes that is confusing to explain but simple to use. The second problemin Figure 14.2 uses both long and short syntax. In long syntax, a goal node (like all nodes) normallymust start with its type,goal , and must also have agoals attribute. However, the short syntax permitsthe type of the node to be omitted when the node starts with a slot name of eithergoal or goals 1
followed by a predicate. The arguments default to the arguments of the first predicate in thegoals slot.In describing problems, it may be useful to use the long syntax which permits specification of constraintssince the arguments can be given explicitly. In long syntax, thearguments andresources slotsmust come before thegoals slot (which must be given).
14.3 Generating Parallel Goals
A process node whose action isgenerate-goalsis special. (For backwards compatibility, parallel-loop
can be used as a synonym for generate-goals.) When interpreting such a node for insertion into a plan,
SIPE–2 generates a split-join with N goals between them. Anydelay , external-condition , or
protect-until slots on the generate-goals node are copied to each goal created.
The generate-goals process node has three other slots it uses:goals , pattern , andarguments .
The pattern is a predicate that is matched in the current world state.2 If there are N possible matches
detected for this predicate, N goals are inserted in the split-join during expansion. When the pattern
has no matches, the system handles the case of no goals being generated as a valid application of the
operator. Handling the degenerate case in this was has proven to be useful in our applications.
1In this case only,goal andgoals are interchangeable.2In versions of SIPE-2 prior to 4.20, the parallel-loop facility was similar but required the pattern predicate to also be in the
preconditions of the operator containing the parallel-loop node. For backwards compatibility, SIPE-2 still accepts this syntax,but significant functionality is lost. In particular, such generated goals are not properly handled by the replanner in that it doesnot recognize when new goals should be added, or old ones deleted. In addition, the operator fails when the pattern has nomatches (either during planning or replanning).
131
Operator: Cleartop-generateArguments: object1, object2 is not object1, block1;Purpose: (clear object1);Plot:Process
Action: generate-goalsGoals: (on block1 object2)Pattern: (on block1 object1)Arguments: object2
Goal: (clear object1);End Plot End Operator
Figure 14.3: Cleartop Operator Using Generate-Goals
Thegoals andarguments slots are used by the algorithm that constructs each goal to be in-
serted.3 Thegoals slot specifies a predicate whose arguments include some of the same variables that
were in the pattern predicate. There are N possible matches for each predicate argument that was also
an argument of the pattern predicate. Any possible matches containing universal variables are ignored.
Using this goal predicate as a template, N goals are created for insertion into the plan. The algorithm
for determining the arguments of the Ith goal instance from the arguments of the goal predicate is as
follows: each argument in the goal predicate that is also an argument in the pattern predicate is replaced
by the corresponding argument of the Ith possible match. For the arguments not in the pattern predicate,
there are two choices: either (1) use the same variable/object for each of the N instances, or (2) create a
new copy for each instance with the same constraints. Option (1) is the default, and will always happen
when the argument is instantiated to a specific object. However, thearguments slot of the generate-
goals node lists variables for which Option (2) should be used. (To get the default behavior, simply omit
the arguments slot.) In this case, the system creates a new copy of the variable for each of the N
instances. Each new variable has only the constraints specified in the operator containing the generate-
goals action. This means any variables used in thearguments slot of the generate-goals node should
not occur in the precondition of the operator (since this would generate system constraints that cannot
be copied). If system-generated constraints do appear on such a variable, they are simply ignored during
copying.
Figure 14.3 shows an example use of generate-goals from the blocks world. Any number of blocks
may be on top of another block and this operator clears an object with a generate-goals action that
generates an ON goal for each block that is on the object to be cleared. This can replace the normal
CLEARTOP operator, which moves one block and then recursively posts the goal again until all blocks
are removed.
Suppose there are five blocks on OBJECT1 when the operator in Figure 14.3 is applied. A split-join
3The slot must begoals notgoal or the parser will think it begins a goal node.
132
with five goals will be created during expansion. Each of the five goals specifies moving one block to
some other location (OBJECT2). Since OBJECT2 is in the arguments of the generate-goals, it will be
a different variable in all five goals (i.e., each of the five blocks can be moved to a different location).
However, each of the five OBJECT2 variables will have the constraint that it is not OBJECT1 since
that was specified in the arguments of the operator. The (CLEAR OBJECT1) goal node that ends the
plot is not necessary for generating actions as it always becomes a phantom. However, it is important
for recording the plan rationale since the five generated goals seek to protect their main effects until
(CLEAR OBJECT1) is true.
The replanner correctly handles generated goals — adding, subtracting, or replacing goals as appro-
priate. The system creates some plan structures to support this, which you may notice in plan drawings.
A Generatenode is inserted in the plan to record the pattern predicate for possible retesting to see if the
N matches have changes. Generate nodes are drawn and printed whenever precondition nodes are. In
addition, a precondition node is generated foreach goal that is generated for a dynamic predicate. These
precondition nodes are used to delete the appropriate subplan if a pattern match becomes untrue.
133
14.4 Syntax for Plots and Problems
The syntax for plots and problems is
plot ::= plot [copy j plot.step�] end plot
plot.step ::= [goal.stepj shortgoal.stepj proc.stepj cproc.stepj par.stepj parexp.stepj
cond.stepj choice.step ]
goal.step ::= fgoal goal.modg goals
shortgoal.step ::= [goal j goals ] predf; g fgoal.modg
goal.mod ::= [[ delay j external-condition j resourcesj sresourcesj argsj protectj
effectsj time j prop-com]]
proc.step ::= process action op-namef; g fproc.modg
parexp.step ::= process action parexpf; g fparexp.modg
cproc.step ::= choiceprocess action op-namef, op-nameg� f; g fproc.modg
parexp ::= [generate-goals j parallel-loop ]
parexp.mod ::= [[ delay j delay-execute j external-condition j args j protect j
goals+ j pattern+ j prop-com]]
proc.mod ::= [[ delay j delay-execute j resourcesj sresourcesj argsj protectj effectsj
time j prop-com]]
par.step ::= parallel fprop-comg branch� end parallel fprop-comg
branch ::= branch numberplot
cond.step ::= cond fprop-comg condbranch� end cond fprop-comg
condbranch ::= condpattern numberpredf; g plot
effects ::= effects predlist
pattern ::= pattern predf; g
goals ::= goals predf; g
protect ::= [protect-until j purpose ] [purpose j predlist]
time ::= [[ [start-time j stop-time j duration ] numerical]]
134
Chapter 15
Customizing the Planner
This chapter describes thePlanningandEfficiencycommands from the Profile menu and explains con-
texts. ThePlanningcommand gives access to the most important variables for controlling planning
functionality, while theEfficiencycommand gives access to variables that can have a significant effect
on system efficiency.
In large domains, the top-level file loaded into SIPE–2 generally contains just SIPE–2 customiza-
tions followed by a series of s-expressions to load files for the sort hierarchy, initial world, and operators.
ThePlanningandEfficiencycommands set global variables. To avoid doing this interactively each time
the domain is loaded, set the global variables appropriately in the SIPE–2 input. The variable names to
use in the input file can be found in this manual, in the fileglobals-customize.lisp , or by edit-
ing the functions mentioned in the Profile menu which is defined in gui-menus.lisp. Variables described
in other chapters can also be set in the input file. In particular, setting the sizes for drawing nodes is
described in Chapter 4, and variables controlling numerical reasoning are described in Chapter 18.
The following variable allows a domain-specific function to be inoked every time a problem is about
to be solved. This can be useful for collected statistics or updating displays.
*init-problem-function* [Variable]This variable can set set to a domain-specific function to apply before each problem is solved. Thefunction should take one argument, a planhead node and a second optional argument which is acontext. The function is called before the problem is copied to a partial plan, and before a plan objectis created.
135
15.1 Controlling Planning Functionality
Variables for controlling planning functionality are in the file globals-customize.lisp which includes
more variables than can be set with the planning-profile menu shown in Figure 15.1. The most important
variables are described below; the others are documented in globals-customize.lisp. Variables set by the
planning profile menu are listed in the order they appear and have the documentation string from the
menu in italics.
Figure 15.1: Menu for Planning Profile
numerical-enabled? [Variable]Enable numerical reasoning capabilities.
Disabling the above capability when it is not needed can improve performance.
new-data-each-level [Variable]Allow user to enter new data at each planning level.
136
If T, the system stops at the beginning of each planning level and asks the user for new information aboutthe state of the world. Algorithms used in the replanner are then invoked to fix the plan in response toany unexpected events. This facilitates planning in a world that is changing during planning. The defaultis NIL .
rededuce-oninstan [Variable]Deductions must be redone after new instantiations.If a domain is such that the deductive operators may produce different results after variables are instan-tiated, then this should be T. If deduction is used extensively, planning can be considerably less efficientwhen deductions must be redone. This has beenNIL in all applications of SIPE–2 to date, andNIL isthe default.
15.1.1 Search Cutoffs
Some domains have the property that certain goals are independent of other parallel actions. Thus,one can declare certain predicate names as independent of parallel actions (using the variable*independent-goals* ), thus allowing the search to cutoff certain search branches. For example,when planning Army and Navy actions in parallel, it may be the case that failures of certain Navy goalscannot be prevented by searching all possible plans for the Army. Thus, these goals are independent ofthe Army plan.
For completeness, if a goal G fails, backtracking still has to try all possibilities for goals in parallelwith G since they may influence later expansions of G. Declaring a goal independent tells the system thatthe parallel goals cannot make G succeed. Thus the search can skip to a backtracking point that preceedsG (skipping backtracking points for parallel actions). Solutions may be missed if the independent goalsdo depend on parallel actions.
*independent-goals* [Variable]The value isT, NIL (the default), or a list of predicate names. The search will skip backtrackingchoices based on the assumption that parallel actions will not affect goals with one of the givenpredicate names (or any predicate name, if the value isT).
15.1.2 Ordering links
plink-enabled? [Variable]Enable links between parallel branches.Disabling the above capability when it is not needed can improve performance.
add-plinks-for-time [Variable]Automatically add links based on timing information.If enabled, causes the system to add ordering links between actions based on information in their start-time and duration slots. This has beenNIL in all applications of SIPE–2 to date; otherwise, an enormousnumber of links are added and the plan becomes unreadable. The system should distinguish betweentiming linksas above, andcausal linkssuch as currently added by the critics. By keeping them sepa-rately, the timing links could be taken into account but not drawn. This has not yet been implemented,although there are plans to do so.
137
*flash-plink-function* [Variable]This variable can be bound to a function of two arguments,(node1 node2) , and the plannerflashes a plink between node1 and node2 only when this function returns non-nil.
15.1.3 User Interaction
automated-planning-display [Variable]Display option after automatic plan generation (:use-menu allows naming).
The value must be one of (:draw :print :use-menu :neither).
automated-replanning-display [Variable]Display option after automatic replanning (:use-menu allows naming).
The value must be one of (:draw :print :use-menu :neither).
interactflg [Variable]User chooses operator to apply.
The value is a boolean, ifT, the user will be asked to choose when there is more than one operator toapply.
automatic-allocation [Variable]Automatically instantiate forced instantiations without asking user.
For variables that are listed oninstantiate slots of operators, this variable directs the system toinstantiate them either automatically or interactively.
*interactive-res-conflict* [Variable]User chooses resource orderings, and how to display them.
If NIL (the default), the planner automatically resolves resource conflicts. If non-nil, the system displaysa menu for each resource conflict and lets the user choose the ordering. The value of this variabledetermines how the conflict is presented to the user before the menu is created. If:draw , the conflictis presented by highlighting nodes on the screen. If:print , the conflict is printed to the lisp listener.If :user-menu , the conflict is described on a menu. If:both , the conflict is both highlighted andprinted.
flash-node-on-expansion [Variable]Flash each node as it is expanded.
If non-nil, the system flashes nodes whenever an ordering link is being added or a node is being ex-panded. This only works if the plan with the nodes is currently drawn on the screen. The default isT.
138
15.1.4 Critics
*fail-on-resource-conflict* [Variable]Prevent resource conflicts with hard constraints.
SIPE–2 provides two different notions of reusable resource. When resource conflicts occur, the systemorders actions to prevent them. For example, when trying to drive two nails, the planner would doone before the other if only one hammer were available. However, in other domains, such as parallelactions being scheduled for different production lines, a resource conflict indicates an invalid plan (thelinesmustbe run in parallel), so SIPE–2 provides the additional option of considering resource conflictsas unacceptable [9]. If this variable isT, the system postsnot-same constraints to prevent resourceconflicts from occurring and never invokes the resource critic (since it is now superfluous).
add-protect-untils [Variable]Automatically protect each action until end of plot.
If T (the default), each action/goal in the plot of an operator is protected until the last node in theplot, unless a specificprotect-until construct is used to specify a different protection interval. IfNIL , no protection intervals are entered into the plan except where theprotect-until construct isexplicitly used.
phantomize-choiceprocess [Variable]Make phantoms out of choiceprocess nodes.
If T (the default),choiceprocess nodes are considered more like goal nodes and are changed tophantoms if their main effects are already true. Otherwise,choiceprocess nodes are consideredmore likeprocess nodes and one of the actions specified is applied.
phantomize-by-constraints-without-ordering [Variable]Instantiate to phantomize, T/NIL/ONE with exception list.
This variable applies in the case when phantomization can happen without ordering any actions. IfT(the default), the system instantiates or constrains variables in order to phantomize goals. This maycause the system to miss solutions by not considering actions to achieve these goals, since it will notbacktrack over this choice. IfNIL , no constraints are posted to achieve a phantomization. If ONE,constraints are posted only when there is only one possibility for phantomization. The value of thisvariable can also be a list as well as a symbol. For a list value, the car of the list is one ofT NIL ONEand the cdr of the list is a list of predicate and action names which are exceptions to the setting in thecar of the list. For example, if the value is given as(t connect) , all goals have constraints addedfor phantomization except a goal to achieve any predicate whose name isconnect . An exception to avalue of ONE is to add no constraints.
phantomize-by-constraints-with-ordering [Variable]Instantiate to phantomize with ordering link (T NIL or ONE).
This variable applies in the case when phantomization can happen only by ordering actions. The systemchecks for possible instantiations that allow it to phantomize parallel goals by ordering them beforeor after other parallel goals/actions. This is done conservatively since solutions can easily be missed
139
by committing to both an ordering and further constraints without the ability to backtrack over thesechoices. If this variable isNIL , the system never posts constraints. IfT, the ordering link and constraintsare added if the only constraints that need to be added arenotpred or not-same constraints. Thisis a conservative approach aspred , same, andinstan constraints are not added. Effectively, thismeans that some plan node phantomizes the goal exactly and the only constraints added are to preventintervening actions from undoing the goal. The default is to set this variable to ONE, the most permissivechoice. In this case, SIPE–2 does what it did in theT case, but in addition postsinstan andsameconstraints, but only when there is only one possible instantiation that lets an ordering phantomize thegoal.
*parallel-phantomize-by-addition* [Variable]Phantomizelevel goals by ordering links to produce/consume effects.
If T (the default), the planner searchs for a set of nodes withproduce and consume effects thattogether accumulate a certain quantity of some resource to make alevel goal true. This phantomiza-tion will require an ordering link for each member of the set. If the value is:one-link , the plannersearches only for a single node that achieves alevel goal by itself, thus adding one, and only one,ordering link. Note that one ordering link may place several produce/consume actions before the phan-tom. If the value isNIL , the planner only phantomizes alevel goal by matching anotherlevelpredicate.
If, in a given domain, no goal is ever phantomized by adding constraints and ordering links at the
same time, setting the last three variables toNIL speeds up planning since the system never searches
for such phantomization opportunities. The following variables are not in the profile menu:
*domain-critic* [Variable]This variable can set set to a domain-specific function to apply as a plan critic. The function shouldtake two arguments, a planhead node and a plan object. The search fails ifNIL is returned by thisfunction.
*domain-critic-frequency* [Variable]Frequency in levels for checking*domain-critic* (1 is default, 0 disables)
15.2 Procedural Attachment
Procedures can be attached to predicates. Attachments should be created with the following function:
declare-proc-att predname arity funct &optional fail-uninstaned [Function]
Predname is a symbol naming the predicate, Arity is the predicate’s arity (an integer), and Fail-uninstaned is a boolean. Funct is a function with Arity number of arguments that is called when theplanner is trying to ascertain whether a predicate with this name and arity is true. If Funct returnsthe symbolFAIL , the planner assumes the predicate did not match. For any other value, the plannerassumes a match.
140
The arguments to Funct are a symbol (an instance name) or a number for each instantiated argument
and a varptr (a consp) for each uninstantiated argument. Handling varptrs requires some SIPE–2 knowl-
edge, so there is an option for avoiding this. If Fail-uninstaned is T for an attachment, then the system
will always return ’FAIL when any argument is uninstantiated, without calling Funct. Alternatively,
Funct may not want to fail when an argument is uninstantiated. In this case, Funct can simply check
if any argument is a cons, do whatever is desired (including accessing the varptr), and then return the
desired value (’FAIL to fail the match, anything else to succeed). Advanced programmers could post
additional constraints on the varptr within Funct (see the functionadd-constraint ).
There is an example procedural attachment indoc/procedural-attachment-example.lisp .
This file includes an attached function that posts constraints on variables.
15.3 Efficiency Profile
TheEfficiencycommand in the Profile menu, whose menu is shown in Figure 15.2, gives access to the
variables in the file globals-customize.lisp that can have a significant effect on system efficiency. Several
items from the planning-profile menu also appear on the efficiency profile because they affect efficiency.
To improve planning time in a given domain, this menu should be studied carefully for options that allow
performance improvement in the domain. The most important variables set in Figure 15.2 are described
below with the documentation string from the menu in italics.
Figure 15.2: Menu for Setting Efficiency Profile
141
One important use of theEfficiencycommand is to set the frequency of application (in planning
levels) of various critics. Critics are always checked before a final plan isaccepted; setting the frequency
of a critic to a number higher than the depth limit effectively applies that critic only on the final plan.
*check-preconds-in-interp* [Variable]Check all future preconditions after every ordering/operator.
Allowable values aret nil :replace :accept :reject . If non-nil,the system checks thetruth of all following preconditions each time an ordering is added or an operator is applied. By check-ing future preconditions, the system can avoid parts of the search space that do not have a solutionsince it recognizes a problem immediately instead of waiting for critics to be applied. If preconditionchecking is fast, this is a win. However, in large domains with complex preconditions this can be toocomputationally expensive, so this variable is often set toNIL in large applications.
Non-nil values control the action taken in a future precondition is found to be false. If:reject(the default), reject this operator expansion and backtrack. If:accept , accept plans with false precon-ditions. If :replace , remove wedge for precondition and replace with root of wedge. Use :replacewith caution – it is in beta-test and backtracking may not work with it. In addition, it is incompatiblewith multiple solutions as replacing wedge will destroy other solutions. IfT, a menu will be displayedfor each false precondition to let the user choose between:replace :accept :reject .
*check-precond-conflicts* [Variable]Check precondition conflicts with parallel actions.
This variable informs the CBG critic about how to protect parallel preconditions, thus permitting pre-conditions to be used in different ways in different domains. If:instantaneous (the default), thesystem checks conflicts with a precondition only at the instant of the precondition. If:purpose , thesystem makes sure that there is no conflict with the precondition anywhere in the interval from the pre-condition to its purpose. IfNIL , preconditions are not checked for parallel conflicts. In large domainswith complex preconditions and many parallel actions, any non-nil value can be computationally expen-sive. Most domains intend preconditions to be true instantaneously, and that is the default semantics ofSIPE–2.
The setting of this variable is determined by how preconditions are used in the domain. This variablecan be safely set toNIL if all predicates affected by parallel actions and placed in the plots of operatorsas goals (to become phantoms), instead of in the preconditions. This is generally what is desired, inany case. The phantoms will be protected by the critics and a parallel action might phantomize thepredicate. If*check-precond-conflicts* is NIL in a domain where precondition conflictsexist, plans may be produced in which certain execution orders of unordered actions may result in aprecondition-test failure in the executor for some precondition. Goals and phantoms are guaranteed truefor all execution orders.
*cbg-frequency* [Variable]Frequency in levels for checking parallel interactions (1 is default, 0 disables).
*resource-frequency* [Variable]Frequency in levels for checking resource conflicts (1 is default, 0 disables).
142
remove-redundant-actions-frequency [Variable]Frequency for precondition-check/wedge-removal (1 is default, 0 disables).
*temporal-frequency* [Variable]Frequency in levels for checking temporal critic (1 is default, 0 disables). The use of the temporal criticis also controlled by other variables as described in Section 18.6.2. Thus, the temporal critic may bedisabled even if the frequency is non-zero.
There is always a tradeoff in how often to apply plan critics. These variables allow control of howmany planning levels pass before each of the given critics is applied. The default is 1, i.e., they areapplied at the end of each planning level. These values can be set to an integer to apply critics lessfrequently or not at all. Critics are disabled entirely if the frequency is set to 0, and are applied to thefinal plan only if the frequency is set to a number higher than the depth limit.
*res-res-conflicts-only* [Variable]Only check resource-resource conflicts, not resource-argument conflicts.
If T, the resource critic may be speeded up by recognizing resource conflicts only when both conflictingactions declare the resource. The default is for a resource to conflict with any argument, whether aresource or not.
recheck-phan-deduce [Variable]Recheck phantoms after adding an ordering link.
If T (the default), this variable tells SIPE–2 that it must recheck phantoms and deductions when it copiesa non-expanded node down to the next plan level. In general, this must be done since further planning atthe next level may have invalidated the deductions or the phantomizations. If, in a given domain, furtherplanning never undoes deductions or phantomizations, the system can be speeded up by setting this toNIL .
15.4 Plan objects
As of version 5.2, SIPE–2 uses plan objects for storing plans. They are largely invisible to users, but
provide developers with a place to record any plan-related information such as assumptions, advice,
justifications, evaluations, critiques, etc. For example, plans saved to files now include advice. There
are API functions for accessing plan structures given a plan name, described below.
Plan objects are used to communicate the context to all system functions.1
Plan objects are used to represent plans in progress (during planning or replanning), partial plans at
each planning level, and final plans. Developers and users can store whatever information they like with
1This facilitates tracing as plan objects print in 1 line, e.g.,<AIR-SUPERIORITY-A-V9-13, 179 choices, IN-PROGRESS>.
143
Plan object Slot Value
name name of plan (bound to planhead of action network)action-network plan nodeaction-network-name name of action network (bound to plan node)context context (list of CPPs)status :final, :partial, :in-progress, or :replanningproblem-name name of problem (bound to partial plan for task solved)last-choice last CPP createdadvice list of advice in effectadvice-scenario name of last advice scenario selectedrequestor name of agent requesting plan (symbol or string)properties property list (not used by system)comment available for general use (not used by system)
Figure 15.3: Important Slots in a Plan object and their Values
each plan object. Two slots are available for this: Properties and Comment, and developers can easily
add other slots to the structure as needed.2
Figure 15.3 show the slots in a plan object (a slot’s value can be accessed by appending ”plan-” to
the slot name, so, e.g.,(plan-name OBJ) will return the name slot). Plan objects are stored on the
global variable*all-plans* , and the plan name in each object is bound to the plan object. The name
of the last advice scenario selected may not correspond to the actual advice used, since the advice might
have been changed after selection of the scenario. Contexts are described in the next section. Here it is
only necessary to know that a context is a list ofCPPs, for “choice-pair-pointers”.
New API functions that find the plan object for a given plan name or plan node are described in
Appendix F.6. Their names are self explanatory, when “plan” by itself refers to a plan object. The most
commonly used such functions are:
find-plan-for-plan-name find-plan-for-name
These global variables involve plan objects:
*last-plan* [Variable]Value is the plan object of the last plan found by the automatic search.
*current-plans* [Variable]Value a list of plan objects for all the plans found by the most recent invocation of the automatic search.
2For now, anyone can restore the old system behavior by evaluating(setq use-plan-record nil) . However,use-plan-record must be set before any plans have been produced in the given domain. If you domain already has plans, eitherreload it or use the Clear Plans command.
144
*current-plan* [Variable]The search algorithms set this variable to the in-progress plan object being used for plan generation.This variable is not changed as drawings are selected in the GUI, so its value may not correspond tothe drawing that is visible.
dcontext [Variable]GUI functions set this variable to the name of the context used for the most recent plan drawing. Thisname is bound to the corresponding plan object.
dcontext* [Variable]GUI functions set this variable to the value of the plan object used for the most recent plan drawing.
15.5 Contexts
The notion of acontextis central to SIPE–2. A context tells the planner which alternatives are part of
the current plan. Plan objects are used to communicate the context to all system functions, except for a
small number of low-level functions that use the internal representation of a context described here.
IMPORTANT! A plan cannot be traversed (e.g., to print or draw it) or even identified unless the
context is right; otherwise, the system stops after the first choice node since it does not know which
successor is in the current plan. If a plan seems to have disappeared, check that the context is correct.
TheList Nodescommand in the Domain menu lists all nodes that are successors of a plan node no matter
what their context. This can be useful in determining if the context is incorrect. If a variable node is
printed with a context ofNIL , all constraints on all contexts are printed. What is usually desired is the
printed representation in one context, so the correct plan object or context must be given as an argument.
The first time a node, G, is expanded, SIPE–2 inserts achoice node into the plan at the beginning
of the new expansion of G. Thereafter, if the search algorithm decides to perform alternative expansions
of G in the same context, these expansions will also be immediate successors of this same choice node.
Thus, if the search is backtracking and there have been 5 operators that were used to expand G (alterna-
tively, the same operator might have been used in 5 different contexts), there would be 5 successors of
the choice node that began G’s first expansion. In this manner, 5 different contexts have been created,
one for each successor of the single choice node. Only one of these successors is part of any single plan,
and the context tells the system which of these successors is in the current plan. Note that thedescand
actionslots of G also have 5 entries pointing to the various expansions at the next level.
It may also be the case that G is expanded in several different contexts (this may happen if G is
preceeded by a set of parallel actions). If G is expanded in 5 different contexts, then it may have
5 descendant choices nodes at the next level, each of which may have a successor for each of the 5
operators.
A context is a list ofCPPs, for choice-pair-pointers. Each CPP is a dotted pair where the car is a
choice node and the cdr is the successor of the choice node that is being selected. In the above example,
145
G’s expansions would produce 5 CPPs, where the car of each is the single choice node, and the cdr of
each is the first node in each alternative expansion. SIPE–2 plan structures are accessed by doingeq
tests on CPPs, so newly consed CPPs cannot be used.
A valid context has a CPP for every choice node that is encountered while traversing the plan. Two
different alternative plans may begin with many of the same nodes, but their different contexts eventually
pick different successors at a choice node. All constraints on variables are indexed by a CPP. Thus, the
same variable will have one set of constraints in one context and a different set in another context. A
dummy CPP(top . top) is used for adding constraints before a choice node has been generated.
How are contexts generated and stored? A CPP is generated whenever an operator is applied to
expand a node (in backtracking, existing parallel expansions and CPPs may be reused). The search
algorithms collect these CPPs as the context for the current solution, and retract them during backtrack-
ing. The search algorithms set the global variable*current-plan* to the in-progress plan object
that contains the context currently being used in the search. If a plan has been completed, the plan object
was given a name and this name can be used to refer to the plan object. Plans are named at the end of
each planning level in the interactive search.
At a break in the middle of planning, the global variable*current-plan* can be used to access
the in-progress plan object, and most frames on the stack have the in-progress plan object as an argu-
ment. Also, each plan node has ansjcontext slot that gives the context necessary for this node. This
context will generally be all the CPPs for choice nodes that occur before the node in the plan, at the
current level and above. Thus, it is not a complete context for some whole plan, but the common subset
of all contexts to which this node belongs.
Appendix F.6 describes funtions a programmer can use to find a desired context, context name, or
plan object from names and plan nodes.
These global variables are use to initialize contexts (also see the variables for plan objects in Sec-
tion 15.4):
original-cpp [Variable]Value is the initial dummy CPP that is in all contexts.
original-context [Variable]Value is the initial context used for every plan.
146
Chapter 16
Reasoning about Partially Ordered
Actions
Advanced concepts:This chapter explains why SIPE–2 is efficient and describes details of ordering
actions. It should be skipped by nonprogrammers and those not concerned with ordering actions that
were once unordered.
This section and Appendix G explain the major extension made to SIPE to produce SIPE–2, and are
partially taken from Sections 3 and 4 in the paper “Can AI Planners Solve Practical Problems?” [9]. In
addition, Chapters 7 and 18 describe reasoning about numerical levels over partially ordered actions.
SIPE–2 has removed the restrictions SIPE previously made on possible ways to order actions. A
planner such as SIPE–2 that supports partially ordered actions is defined as anonlinearplanner. A plan
is partially ordered if it contains actions that are unordered with respect to each other, i.e., actions for
which the planner has not yet determined an order and which may possibly be executed in parallel. If
a planner has the ability to represent and reason about partially ordered plans, it can avoid committing
to a particular ordering of actions until it has accumulated information that permits determination of
the correct ordering. This strategy can avoid an exponential search of all possible plan orderings as is
typical of a linear planning system. For example, 52 actions unordered with respect to each other have
as many possible orderings as the number of ways a deck of cards can be shuffled. This is an enormous
number, and a nonlinear planner can often avoid searching such prohibitively large search spaces.
Another advantage of nonlinear planners is that actions can remain unordered in the final plan,
thus permitting parallel plans to be generated; this is a necessity in many domains. The planner must
order actions during the planning process to ensure that no harmful interactions occur among unordered
actions. Actions generally remain unordered until such time as the planner discovers the order it wishes
to impose. For this reason, nonlinear planners are often referred to as employing theleast-commitment
approach.
147
A planner’struth criterion (TC) is its algorithm for determining whether a formula is true in a
particular world state. From an efficiency standpoint, the TC is the heart of the planning system; it is a
primitive operation used in every planning algorithm. Unfortunately, nonlinearity makes SIPE–2’s TC
NP-complete [8]. To ensure soundness when the TC makes a query predicate true, the system needs to
determine all possible orderings that would make the query true, then constrain the plan to allow only
these orderings. This process is exponential, and is the underlying reason why nonlinear planners that
make only sound deductions at each step are not practically useful. Of course, the soundness of the final
plan should be guaranteed. As discussed below, SIPE–2 has heuristic algorithms for avoiding some of
the combinatorics.
16.1 Efficiently Handling Partially Ordered Actions
SIPE–2 incorporates mechanisms and heuristics for circumventing the NP-complete problem of the
TC. The high-level description of these mechanisms in this section applies to SIPE as well as SIPE–2,
although different implementations are needed to achieve these mechanisms in the two systems (see
Appendix G). The most powerful heuristic for avoiding combinatorics is that the TC does not always
enforce the ordering constraints that would ensure soundness. Thus, invalid plans may be temporarily
produced. The system relies onplan critics that check for and correct problems in these plans. These
critics are applied aftereachplanning level, i.e., an expansion of the whole plan to a greater level of
detail, though the user can control the frequency of critic application as is appropriate for the problem
domain. One could view this as doing the work of enforcing validity every so often instead of at every
primitive step.
The TC merely proves that there is one possible ordering of the partially ordered actions that makes
the query predicate true, without enforcing that order. Proving that there is one possible ordering is
efficient, as the ordering itself need not even be calculated, and there is certainly no need to calculate
all such orderings. Roughly, this is because the system needs only to find an action that (1) achieves the
query predicate, and (2) does not have an action that negates the query predicate that necessarily follows
it. This algorithm can produce temporarily invalid plans, since different calls to the truth criterion may
assume different implicit orderings. The idea of defining conditions that make planning operators sound
is unlikely to lead to a heuristically adequate, nonlinear planning system.
If problems are detected by the critics,solversare applied to modify the plan, possibly adding
ordering constraints to the actions. Solvers in SIPE–2 are powerful as they use the replanning actions
of the system to modify plans [8], possibly removing subplans in order to make better plans. The
invalid plans temporarily produced have not been a problem in practice, primarily because appropriate
heuristics and algorithms have been developed. The TC has proved to be a useful compromise that
provides the user with a powerful tool to produce useful plans efficiently.
148
16.2 Considering All Possible Orderings
SIPE had anonshuffling restriction[8] that made the critics and solvers simple and efficient. Given a set
of subplans that are unordered with respect to each other, SIPE would order them only by putting one
whole subplan before or after the others. This greatly reduced the number of possible orderings, but it
could not produce all possible shuffles of the primitive actions in the subplans. While this assumption
is reasonable when planning the actions of a single robot in an environment without other agents, it has
proven too restrictive in problems with multiple agents or conjunctive goals. Effects of this restriction
even appeared in the blocks world, as SIPE obtained a nonoptimal solution for the Sussman Anomaly
when the initial goal is given as the two unordered conjuncts (On A B) and (On B C) [9]. SIPE–2, which
does not have the nonshuffling restriction, produces optimal plans for all 3-block block-world problems.
In addition to the evidence from the Sussman Anomaly, planning the construction of buildings and
structures shows the inadequacy of this nonshuffling restriction. Consider the problem of building a
deck that is supported by four beams which are in turn supported by four columns sunk in concrete
footings. The natural hierarchical decomposition of this problem is to plan the construction of the four
beams in parallel and then lay the deck on the beams. Constructing a beam consists of constructing
its two supporting columns. Ordering constraints must be added as two different beams require the
construction of the same column. With the nonshuffling restriction, a planner can only produce a plan
that constructs two footings, then constructs two columns, then lays a beam across those two columns,
and then proceeds to the next footing and column. This is not acceptable as the workers who lay the
concrete have to wait between the second and third footings for the carpenters to construct columns
and beams. A plan that had all footings in parallel followed by all columns in parallel would be much
preferable. SIPE–2 produces a plan with a minimal number of ordering constraints for this problem.
One possible ordering implicit in this plan, and produced by theRegroupcommand in the Plan menu, is
the one with all the footings, columns, and beams in parallel.
Because of the unacceptability of the nonshuffling restriction, SIPE–2 allows all possible orderings
of unordered actions while maintaining its efficient truth criterion. SIPE–2 permitsparallel linkswhich
are defined as successor and predecessor links that can be placed between any two actions in a plan that
are unordered with respect to each other. Such links will be referred to as p-predecessor and p-successor
links to distinguish them from successor and predecessor links that have always been part of the plan.
This is done because the plan-traversal algorithms must follow these links differently (see Appendix G).
The representation of parallel links is complicated by the use of hierarchical planning levels and
SIPE–2’s ability to represent alternative plans in different contexts. There may be a number of parallel
links at any one node, e.g., there may be multiple p-predecessors. However, some links may apply not
to the current plan and context but rather to an alternative expansion of the plan. There are also com-
plications in copying these links down to more detailed expansions of the plan, since some nodes may
be expanded to the more detailed level while other nodes may not be. For efficiency, the system keeps
149
parallel-pred-here andparallel-succ-here slots at lower levels when links can be calcu-
lated, rather than recomputing links by following the higher-level links stored in theparallel-pred
andparallel-succ slots (see Appendix F.3).
16.3 External-Condition Goals
With the new capability provided by parallel links, the user needs new ways to specify domain-specific
knowledge about orderings. This need was met by allowing certain goals in operators to be specified
asexternal-condition goals. Such a specification indicates that the goal is not to be achieved
by planning a sequence of actions; instead, it will be achieved by actions external to this operator and
“phantomized” by inserting an ordering link. In other words, this goal will be achieved by waiting until
some other action achieves it. External-condition goals are necessary in the construction domain: e.g.,
if finishing the walls is proceeding in parallel with electrical wiring, there must be some way to specify
that the portion of the wiring inside the walls must be finished before the walls are completely enclosed.
This can be accomplished by having an external-condition goal of finishing the internal wiring placed
before the goal of closing the walls in the plot of an operator which specifies the actions for finishing
the wall.
150
Chapter 17
Using Deductive Rules
Advanced concepts:This chapter describes intricate details of deductive rules, and should be skipped
by those not intending to use this capability.
Deductive rules allow effects of an event to be deduced without being mentioned explicitly in the
plots of operators, thus permitting deduction of context-dependent effects. Like all parts of SIPE–2, they
are described in detail elsewhere [8]. Deductive rules allow expression of domain constraints within a
world state, and permit access to different world states. By accessing different world states, the system
can react tochangesbetween two states, thus permitting deduced effects concerning what happened
during an action even though these effects might not be implied by the final world state. This provides
a fairly powerful and expressive formalism for improving operator specification.
SIPE–2 deductive rules have triggers, preconditions, conditions, and effects. The trigger controls
rule application because it must match an effect of the node of current concern before the rule can be
applied. If the precondition and condition of a rule hold, the effects of the rule can be added as effects
of the node. Triggers and conditions are always matched in the current world state while preconditions
are matched in the previous state.
All deductions that can be made are performed when a new node is inserted in the plan. The
deduced effects are recorded and the system can then proceed as if all the effects had been listed in the
operator. However, deductions are recomputed whenever the planner does something that may affect
their computation. For example, deductions are recomputed when copying a node to a lower planning
level, since a further expansion of an earlier action may cause different deduced consequences. Deduced
effects can also be recomputed after instantiations of planning variables (seerededuce-oninstan
in Chapter 15).
The division of deductive rules into init-operators, causal-rules, and state-rules is used to control
their application. Init-operators are used only in the initial world. Causal rules are applied before state
rules.
151
Initially, all causal rules whose trigger matches a node-specified effect are applied, thereby pro-
ducing an additional set of [deduced] effects for that node. After all such rules have been applied, the
system determines which newly deduced effects were not already true in the given situation and permits
the causal rules to trigger on these recursively. This process continues until no effects are deduced that
were not already true, thus computing the deductive closure of the causal rules. This process is then re-
peated for the state rules, initially firing them on all node-specified effects and all effects deduced from
causal rules. In this way, the deductive closure of all deductive rules is computed while maintaining
control of the deductive process and preventing deductive loops.
The idea behind dividing the rules into two sets is that rules about causal events should be matched
before constraints about the domain. Both types of rules are permitted to have both conditions and
preconditions (or neither), so they have identical expressive power. However, in all domains yet im-
plemented, state rules never have a precondition (only a condition) while causal rules always have a
precondition (and perhaps also a condition). Thus the causal rules are reacting to changes between
states, while deductive rules are enforcing constraints within a state. The system interprets causal rules
and state rules identically, except for their order of applicability. This gives the user more power and
flexibility by not enforcing limitations.
A paper [7] describes efficiency issues in deduction for planning, particularly those encountered
when reasoning about locations of objects and aggregate objects (i.e., objects that can be split into
subparts and later aggregated). This paper is entitled “Reasoning about Locations and Movement in
Theory and Practice”, by Karen L. Myers and David E. Wilkins. Some of its conclusions are presented
later in this chapter.
17.1 Existential and Universal Quantifiers
The closed-world assumption leads to restrictions on the use of quantifiers. Formulas of the form
9x:P(x) and8x::P(x) are relatively easy to compute since they involve searching for occurrences of
unnegated predicates. Existential variables can appear only in preconditions and conditions, and are
used to represent both these forms. In negated predicates, the scope of the existential quantifier is (by
definition) within the negation, yielding a formula equivalent to the previous universally quantified for-
mula. The scope of each existential variable is local to the predicate in which it occurs. A heuristic is
used to calculate the truth of existentially quantified variables (which further keeps the quantifier from
being equivalent to a quantifier in logic); it is described elsewhere [8].
Universal variables are permitted in deductive rules. As expected, a universal variable in the effects
of a node means that the effects are true for all objects that match the variable (taking into account the
constraints on the variable). However, universal variables in preconditions are treated like any other
variable, i.e., the variables are constrained so that they match all and only those objects for which the
152
Causal-Rule: at-regionArguments: object1,region1,region2 is not region1;Trigger: (at object1 region1)Precondition: (at object1 region2)Effects: (not (at object1 region2))
State-Rule: at-regionArguments: object1,region1,region2 is not region1 class universal;Trigger: (at object1 region1)Effects: (not (at object1 region2))
Figure 17.1: SIPE Deductive Rules With and Without Universals
precondition is true. The system does NOT prove that the precondition is true for all values of a universal
variable.
The causal rule shown in Figure 17.1 deduces that an object is no longer where it used to be after
it moves. It matches its precondition to determine the previous location of the object. The preferred
method for doing this deduction is the state rule in the same figure. Since an object can be at only one
location, the state rule deduces that the object is not at any location other than the current one. Because
of the universal variable, the previous location need not even be determined. Section 17.3 discusses the
advantages of using universals.
Care should be used in posting universal effects for predicates that will later be matched to negated
existentials. In one case, the negated existential will still match as expected: if the universal effect is on
an unnegated predicate (i.e., a possible clobberer of the negated existential) and the effect has only one
universally quantified argument with more than one possible instantiation. Beware of using universal
effects on negated predicates when a negated existential will later be matched to that predicate.
17.2 Init-Operators
Init-operators are applied to the initial world model only when(init.deduce) is called. Init-
operators ignore negated predicates that are deduced for closed predicates. Also, when a predicate
is deduced with uninstantiated variables in it, one predicate for each possible legal instantiation of
the predicate arguments is added to the world model. Any operator declared as an init-operator (or
a both-operator ) has both its precondition and condition matched in the current world state.
Otherwise init-operators behave the same as other deductive rules. If an operator is defined as
both-operator then it becomes both an init-operator and a state-rule.
153
17.3 Efficiency Issues
Uninstantiatedvariables greatly increase the computational complexity of doing deductions, particularly
if many instantiations exist. Chapter 10 describes forcing instantiations by using theinstantiate
slot in an operator definition. This technique can speed up deductions by one or more orders of magni-
tude if key variables are instantiated. Similarly, declaring functions asno-range-functions (see
Chapter 12) can greatly speed up deductions involving variables whose constraints apply functions to
uninstantiated variables.
Using deduced effects containing universal variables can greatly decrease the cost of deductions.
Certain predicates arefunctionalin certain arguments, indicating that the predicate can only have one
valid instantiation for such an argument at any point in time. Universal variables should be used to
efficiently deduce that a functional predicate is true for this one particular argument but not true for any
other.
When(at bill whitehouse) is an effect of an action, it triggers a state-rule like the one shown in
Figure 17.1 that deduces an effect of:(at bill x) where x is a universal not-equal to “whitehouse”.
This capability provides more power and flexibility than using a functional syntax (e.g.,at(bill ) =
whitehouse). For example, any number of the arguments to a predicate may be universal, and combining
a constrained variable with this universal quantifier effectively represents a certain subset of objects.
Several advantages accrue from using the universal state rule instead of the causal rule. One ad-
vantage is that the state rule does not have to match a precondition to determine the old location of the
object, so the rule application itself is quicker. However, a more important advantage comes from the
fact that the action with the AT effect and the universal negated AT effect now completely determines
the truth of any query about that object’s location. This means the algorithm for determining the location
of this object can terminate at this action and return a unique answer, instead of traversing all the other
actions in the plan and returning a list of possible locations. In addition to making the algorithm faster,
this produces smaller constraints on the locational variable, which it turn makes every algorithm in the
planner more efficient.
A comparison done in one large SIPE–2 application shows the importance of using universal vari-
ables. When the state rules were replaced by the corresponding causal rules (as shown in Figure 17.1),
the time to generate a typical plan increased by 20% (from about 4 minutes to about 5 minutes).
17.4 Pitfalls — Important!
The system constrains variables in an attempt to match a deductive rule, but only when the two variables
are initially constrained to be of the same class. However, it may not be desirable to do this since the
instantiation so forced may prevent a solution to the problem from being found. If a causal rule requires
154
further specification of a variable’s class, it will fail: it is assumed the user did not intend the deduction
in this case. Thus the user can control the forcing of instantiations by the classes used in causal rules.
As an example, consider the blocks world (see Appendix A). Suppose you are moving a block from
some object that is a variable (object1 ), and suppose you have a deductive rule for deducing that an
underneath block (block1 ) is clear whenever a block is moved from its top. If further specification of
class were allowed, applying this deductive rule would constraintobject1 to be a block so that the
rule could deduce that it was clear. This may miss solutions where a block has to be moved off some
nonblock object. As implemented, the system refuses to do this until theobject1 variable has been
further constrained to be a block. It would also do it if the deductive rule specifiesobject1 class
blocks instead ofblock1 . In this case, the initial class constraint is the same, so it is assumed the
user intends further constraints to be posted. These issues are discussed in more detail elsewhere [8].
It can be tricky to get deductions just right. The user should keep in mind the matching algorithm
which goes back through the plan until it finds an effect that matches a given predicate. As discussed in
detail elsewhere [8], problems can occur when deductive rules assume that previous parts of the plan are
at a certain abstraction level. SIPE–2 does not concern itself with the abstraction level of a plan unless
the user selects the ABSTRIPS control option in the user profile. If this is selected, the user must define
a function named LEVEL which takes a predicate name as argument and returns an integer representing
the abstraction level of the predicate. Another method of coordinating abstraction levels [8] involves
having an operator that copies the current node down one level until the rest of the plan reaches the
correct level.
An operator that deduces(p x y) from (p y x) is fine. If the user starts with(p a b) in
the world model, the first round deduces(p b a) which is new and triggers the deduction of(p
a b) , which is already true so the operator is never triggered again. Care must be taken to have
deductive operators that trigger on every possible predicate that may be added to enable the deduction.
For example, suppose a state-rule has a condition of(p x) and(q x) . If all instances of predicate P
are given as main effects and only instances of Q are deduced, then a trigger of(q x) is sufficient. If,
on the other hand, both instances or P and Q are deduced, then the trigger should be(or (p x) (q
x)) .
155
Chapter 18
Numerical Reasoning
Advanced concepts:This chapter describes intricate details of numerical reasoning, and should be
skipped by those not intending to use this capability.
SIPE–2 has mechanisms for reasoning about numerical quantities, both continuous and discrete,
which provide the basis for reasoning about producible and consumable resources. These mechanisms
have been integrated within the existing framework of adding constraints to planning variables. The
user invokes these mechanisms simply by declaring variables to be in the numerical class, and using
constraints and certain distinguished predicates on them.
This design provides flexibility, as constraints can be posted on numerical quantities. It provides a
basis both for reasoning about producible and consumable resources and for limited forms of temporal
reasoning. Time is treated as a consumable resource that can be consumed but not produced, and whose
consumption over parallel tasks is nonadditive.
The system can employ all its standard planning algorithms to solve numerical problems by treat-
ing numbers as objects, and by providing numerical variables, numerical constraints, and numerical
predicates. The system automatically computeslevel predicates from predicates that produce and
consume numerical quantities, and the user can specify goals and preconditions that involve these lev-
els. The system notices when a set of actions that produce a resource together satisfy alevel goal.
First, we describe the representations used for numerical objects, constraints, and predicates. Following
that, we show how the representation is used to reason about consumable resources. Then, we describe
how these representations are manipulated by the system.
Because of the complexity of reasoning about numerical quantities during planning, the descriptions
in this chapter are often best understood by example. The input domain in Appendix B uses numerical
quantities.
156
18.1 Numerical Objects
Numerical objects can include numbers, lists of numbers, ranges, and functions. These can be instan-
tiations of planning variables or values of constraints posted by either the user or the system. Lists of
numbers are provided for temporal reasoning along the lines of Ladkin’s TUS syntax [3]. The follow-
ing two global variables control the reasoning about lists of numbers. They can be set by using the
Numericalcommand in the Profile menu, which brings up the menu shown in Figure 18.1.
Figure 18.1: Menu for Numerical Profile
numerical-template [Variable]The value of this variable should be a list of numbers used as the limits for carrying when adding twonumbers. Instead of numbers, the following recognized symbols can be used:(seconds minuteshours days months years) . These correspond to the obvious numbers, except that thecomputation of days carrying into months is adjusted for months of 28, 30, and 31 days. The defaultvalue is shown in Figure 18.1. The user can customize the temporal representation simply by settingthis variable to some other list. For example, one could use just days, months, and years, or (60 24)when planning the events of a single day down to the hours and minutes.
smallest-unit-first [Variable]If T (the default), two lists of numbers are added by adding the numbers in the order they appear in thelist. If NIL , they are added in reverse order. For example, a list of numbers intending to represent(day month year) would requireT for this variable, while a list of numbers intending torepresent(hour minute second) would requireNIL .
Lists of numbers have the same status as do numbers and can occur anywhere a number is required
(e.g., as the lower bound of a range, as the value returned by a function, or as the instantiation of a
variable). Ranges are pairs of numbers that represent the lower and upper bounds of a range. Functions
are represented by the function name and by a list of arguments that can be any objects or planning
variables known to the system. The function must return a number whenever it is called with instantiated
arguments.
18.2 Variables
Variables can be constrained to be members of two distinguished classes,numericalandcontinuous.
The first is used for variables that will eventually be instantiated to one particular number, just as an
157
ordinary variable is instantiated to an object. For example, this would be used to represent the starting
time of a planned action. Variables in the continuous class have values that vary with time as actions are
performed and must be computed by the system. These can be used to represent the level of a consum-
able resource, e.g., the amount of petrol in a fuel tank. To finalize a plan, numerical variables should be
instantiated to numbers, while continuous variables merely need to have satisfiable constraints.
When to use a continuous variable can be confusing. The only situation in which a continuous
variable should be used is when reference is being made to a quantity that varies over time as actions
postproduce andconsume effects. Every other numerical variable should not be continuous because
it is not necessary to compute a value that changes over time. In particular, any quantity that is produced
or consumed at a node should be a fixed quantity — it is only the total to which the produce/consume
is adding that is continuous. Continuous variables should be used only when SIPE–2 must compute
the value of a continuously changing quantity. For example, in the missionaries and cannibals problem
(Appendix B), the number of cannibals on either side of the river is represented by a continuousvariable.
The actions of moving across the river postproduce andconsume effects, which are used by the
planner to compute the continuous variable.
Continuous variables introduce complications. They cannot havepred constraints, which guaran-
tee that predicates will be true at particular times, since they change values over time. A continuous
variable may be instantiated (see Section 18.5), which has the effect of constraininglevel predicates
that contain this variable to always compute a value that matches the given instantiation. Thus, the
constraint-satisfaction critic must check all phantom and precondition nodes in the plan which contain
predicates with continuous variables as arguments and ensure that the continuous variables have the
right value at particular times.
The termnumerical variablewill be used to refer to members of either the numerical or continuous
classes (the continuous class is implemented in the sort hierarchy as a subclass of the numerical class).
18.3 Constraints
Summarized below are five numerical constraints that may be posted on numerical variables, but not on
continuous variables nor on any nonnumerical variables. Other nonnumerical constraints may also be
posted on numerical variables. The use of these constraints is described in more detail following the
summary. The constraints are these:
� Current-value— A numerical variable can be constrained to be the current value of a continuousvariable at some point in the plan. This permits operators to reason about and place constraintson the value that some continuous variable has at some particular point in time.
� Previous-value— This is the same as current-value, except that the value is taken just before thecurrent node instead of just after it.
158
� Range— A variable can be constrained to lie within a certain range.
� Function— A variable can be constrained to be the value of a certain function applied to any num-ber of arguments. If some of these arguments are not instantiated, SIPE–2 computes a range fromthe function constraint by calling the function on all the possible instantiations. For efficiency, itis often desirable to not compute these ranges.
� Summary-range— Since computing the above constraints (especially function constraints) can beexpensive, it is necessary to address the problem of choosing between storage and recomputation.Our solution is to store the results of computing a noncontinuous variable’s constraints by plac-ing a summary-range constraint on the variable. (This cannot be done for continuous variablesbecause their values vary with time.) These constraints are not posted by users but only by thesystem.
The syntax for numerical literals and constraints(from Section 13.2) is
literal-arg ::= [object-namej expr-formj numericalj functionj range]
numerical ::= numberj ( number�)
function ::= ( symbol[numericalj symbol]�)
range ::= [ numericalf, g numerical]
constraint ::= class-conj quant-conj is-conj with-conj same-con
is-con ::= is [is-not j is-currentj numericalj expr-formj function
j rangej object-name]is-current ::= [current j previous ] value of continuous-arg-name
18.3.1 Function Constraints
A function constraint is placed on a variable by a declaration in the arguments slot of an operator. The
syntax is as follows:
numerical1 is (fname arg1 arg2 . . . argn)
As of version 4.16, SIPE–2 supports computing chains of function constraints in both operators
and deductive rules. In other words, one function constraint in an operator can have as an argument a
variable from the operator that is in turn constrained by a constraint constraint.
When function constraints are used, SIPE–2 expects the given name (i.e.,fname in the above
example) to be either the name of a Lisp function or the name of an attribute in the sort hierarchy. The
arguments to the Lisp function can be any SIPE–2 argument, and it should return eitherT or a SIPE–2
numerical object. If there is no defined Lisp function of the given name, the name is interpreted as
referring to the name of an attribute in the sort hierarchy, there should be one argument, and the returned
value is the value of that attribute for the given argument. The variable*current-node* can be used
inside functions:
159
*current-node* [Variable]Value is the node currently being expanded by the planner.
For doing arithmetic directly on SIPE–2 numerical variables, the system provides the following
predefined arithmetic functions, each taking two arguments:
SIPE+ SIPE- SIPEMAX SIPEMIN SIPE* SIPE*-ROUND
Before writing Lisp functions, the programmer should look at these functions in numerical-util.lisp or
the examples below to learn how to access variables.
Note that when the system processes function constraints whose arguments are uninstantiated vari-
ables, it tries all possible sets of instantiations to compute a range for the value of the function.
This can be inefficient; for example,duration1 is (travel-time loc1 loc2) would call
travel-time n�m times if there aren possible instantiations forloc1 andmpossible instantiations
for loc2 . In some domains, computing this bound forduration1 may be crucial to finding a plan,
but in other domains this computation may be expensive and unnecessary. This computing of bounds
can be avoided by declaring certain functions names to be computed only when their arguments are
instantiated. This can be done with a declaration in the input file (see Section 12.3), or by setting the
following variable:
no-range-functions [Variable]Value is a list of all function names that are not computed until their arguments are instantiated. Thedefault value is(SIPE+ SIPE- SIPEMAX SIPEMIN SIPE* SIPE*-ROUND) . Values shouldbe consed onto this list, unless it is desired to compute ranges for some of these arithmetic functions.
The following functions provide examples of functions that take variables as arguments and return
numbers:
(defun size (x) (car (get-attribute x ’size))) ;default
(defun twicesize (x) (* 2 (car (get-attribute x ’size))))
(defun number-of-cartons (duration packaging-rate)(if (or (not (numericalp (setq duration (num-or-vp duration))))
(not (numberp (setq packaging-rate(num-or-vp packaging-rate)))))
;num-or-vp extracts numerical objects if its arg is instantiatedt ;if any not instantiated, do not post constraints(* (+ (car duration) (/ (second duration) 60)) packaging-rate)))
;This function uses *current-node* to get the value of the sea-state so it; is available without waiting another plan level for the planner;to instantiate it (by having the sea-state predicate as a precondition).(defun current-sea-state (sea-sector latest-start
&aux (pred (create-sea-state-predicate sea-sector latest-start)))(matchcond (list pred) *current-node* *current-plan*)
160
(num-instanp (third (parguments pred)) *current-plan*))))
;Create a sea-state predicate to query the sea-state.(defun create-sea-state-predicate (sea-sector latest-start &aux newpred)
(setq newpred (make-predicate-node))(set.predname newpred ’sea-state)(set.parguments newpred
(list (cons ’sea-sector1 sea-sector)(make-des-or-ptr latest-start ’worldmodel) ;for numbers(cons ’numerical1 (make-indef numerical nil original-cpp))))
newpred)
Size would not have to be defined since it merely reproduces the default behavior of returning the
size attribute from the sort hierarchy (ifsize is used as a function without being defined).Twicesize
returns twice the value of the size attribute.Number-of-cartons returns the number of cartons
produced when operating at a given rate for a given amount of time.Duration will be instantiated
to a two-element list where the two elements represent hours and minutes. Note thatnum-or-vp is
called to extract numerical objects from numerical variables, and thatT is returned if either variable
is not instantiated. This practice should be followed on all user-functions that operate on numerical
variables.
18.3.2 Current-value and Previous-value Constraints
A current-value or previous-value constraint is placed on a variable by a declaration in the arguments
slot of an operator or a deductive rule. The syntax is as follows:
numerical1 IS CURRENT VALUE OF continuous1
numerical1 IS PREVIOUS VALUE OF continuous1
These constraints are used to bind a numerical variable to the value of a continuous variable at
a particular point in time. For example, a continuous variable may represent time, and the user may
wish to bind a numerical variable to its current value in order to bind the starting time of the action
currently being planned. These constraints apply to a particular node, let’s call itcv-node, in the plot
of the operator in which they are defined. Cv-node is defined to be the first plot node that has either
numerical1 or continuous1 in its arguments. If none do, then the precondition node inserted by the
system at the beginning of the plot is used.1 If the operator has no precondition, and does not mention
numerical1 or continuous1 in its plot, then SIPE–2 may ignore these constraints.
1The eventual cv-node can be determined only when the plot nodes are converted to plan nodes. When applying theoperator, SIPE-2 initially uses thenode being expanded as the cv-node. This allows matching of the constraint before the plotis processed (e.g., while checking the precondition). When the plan nodes are created from the plot, the system then beginsusing the newly created cv-node.
161
For a current-value constraint, the system takes the value after the effects of cv-node have been
taken into account. For a previous-value constraint, the value is taken without processing the effects of
cv-node.
A current/previous value is computed by constructing and matching alevel predicate (described
in Section 18.4) that has both numerical1 and continuous1 as arguments. The level predicate can also
have nonnumerical arguments that identify the particular “level” being measured. Since this “level” will
generally be used somewhere in the operator, the system gets additional arguments to the level predicate
it constructs by looking in the operator instead of requiring the user to specify them. The algorithm
for determining the arguments to the level predicate looks first through the effects of cv-node and then
through the precondition of the operator. It uses the firstlevel , produce , or consume predicate it
finds that has either numerical1 or continuous1as an argument (it should have both as arguments). It then
uses the argument list of the predicate so found as a template for the arguments of the generated level
predicate. If no template is found, then (level continuous1 numerical1) is used as the level predicate.2
18.4 Predicates
Several distinguished predicates are treated specially by SIPE–2. These areproduce, consume, level,
level<, level>, level<=, andlevel>=. These predicates occur at certain points in a plan and operate
on the values of continuous variables at those points. All these predicates can be viewed as having two
arguments — one specifying the quantity being compared (e.g., the resource pool or fuel depot), the
other specifying the numerical value that is being produced or consumed, or that must be equal to the
value of the specified quantity. The specification of the quantity can, in fact, be a tuple of normal SIPE–2
arguments (i.e., variables and objects known to the system). The specification of the numerical value
is computed by taking into account all applicable nodes whose effects containlevel , produce , and
consume predicates. All fivelevel predicates can be used in preconditions and goals.
18.5 Accumulating Numerical Quantities
In many application domains, it is necessary to accumulate a certain quantity of some resource. Ex-
amples include getting a sufficient number of troops and meals to the destination during a military
deployment, and moving a sufficient length of boom to surround an oil spill. Such goals are notaccom-
plished by a single action; rather, several actions contribute to the accumulation. This capability is also
required for reasoning about consumable resources; for example, the amount of fuel in an automobile.
2Some users may want a more detailed description of the evaluation of a current-value constraint. Briefly, the con-structed level predicate is matched byworldcollect at the lowest-level expansion of cv-node in the current context.Worldcollect returns the predicate it computes that causes the level predicate to match. From this returned predicate, wecan get the argument corresponding to numerical1 and use its summary-range constraint (or instantiation) on numerical1 toenforce the current-value constraint.
162
Operator: Fuel-PutonArguments: block1, object1 is not block1, robot1,
numerical1 is (Size block1), continuous1 is (Size block1);Purpose: (on block1 object1);Precondition: (Level> robot1 continuous1);Plot:Parallel
Branch 1: Goals: (clear object1);Branch 2: Goals: (clear block1);
End ParallelProcessAction: Puton.Primitive;Arguments: block1,object1,robot1,numerical1;Resources:block1;Effects: (on block1 object1),
(consume robot1 numerical1);End Plot End Operator
Problem: Prob1Goal
Arguments: block1 is not A, B;Goals: (on block1 B);
GoalArguments: robot1, continuous1 Is [5 50];Goals: (level robot1 continuous1);
End Problem
Figure 18.2: Block-World Operator Using Consumable Resources
Such numerical quantities are implemented in SIPE–2 through the use oflevel , produce , and
consume predicates and appropriate numerical variables. This section presents two examples: (1)
extending the block world to have the robot use fuel as a consumable resource, and (2) planning to
move a sufficient length of boom to surround an oil spill.
18.5.1 Consumable Resources
To reason about consumable resources, we assume that different blocks have different sizes and that
block-moving actions use up the robot’s fuel as a function of block size. SIPE–2 can represent this
world and generate plans that require both selection of the correct operator and selection of smaller
blocks so as to achieve fuel goals. The complete input for this domain is in the SIPE–2 distribution (see
Appendix A).
163
The Fuel-Puton operator, shown in Figure 18.2, consumes the same number of units of fuel as there
are units in the size of the block being moved. A simple problem in this domain is also shown (both are
given in the input syntax). The problem requires the robot to get some block other than A on top of B
and afterward have at least 5 but not more than 50 units of fuel remaining.
Fuel-Puton has three arguments in addition to those used in Puton (in the standard block world).
These are the robot, a numerical variable for calculating the amount of fuel used by this operator, and
a continuous variable used in the precondition to ensure that the continuously varying fuel level of the
robot is sufficient for this operator. Since the domain requires only one numerical level to be associated
with the robot, the fuel level can be represented by the predicate(Level robot1 continuous1). If the
robot had other levels, another argument could be added to the predicate, since SIPE–2 permits a tuple
of arguments to represent the quantity with which a numerical value is associated. (Any predicate with
a different number of arguments refers to a different quantity).
The precondition of Fuel-Puton ensures that the robot has enough fuel toaccomplish the actions
of this operator (i.e., enough fuel to moveblock1). The argument to the precondition has a continuous
variable, so the planner computes the value from the produce and consume effects in the plan. In this
case, the continuous variable is also constrained to be the size of block1. Thus, thelevel> predicate
matched only if the computed level is greater than the size of block1. The truth of this precondition is
continually checked by plan critics throughout the planning process as actions are added to the plan that
may affect the level.
In the initial world, the level of fuel can be specified with alevel predicate. As actions are per-
formed, they use and replenish fuel. An action that uses fuel simply specifies, in its effects, aconsume
predicate that denotes which fuel tank is being used (by giving the robot as the first argument), and the
amount of fuel that is consumed (this second argument may be a function, a range, a number, or a list of
numbers). Thus, the Fuel-Puton operator has aconsumepredicate in the effects of its plot.
The system takes this consumption into account in all queries about the fuel level, which may involve
determining ranges within which the consumption must lie if the predicate has uninstantiated variables
as arguments. Similarly, an action that replenished the fuel would post aproduce predicate as an
effect. Alternatively, an action that always filled the tank to some known level could simply post a
level predicate as an effect. Such alevel specification overrides previousproduce andconsume
predicates, in the sense that the system will no longer look at them to calculate the fuel level, which is
now given by thelevel predicate.
18.5.2 Recursive Accumulation
It has been common in SIPE–2’s domains of application to use numericallevel predicates recursively
to accumulate a certain quantity of some resource. Figure 18.3 shows a slightly simplified operator (in
input syntax) from the oil-spill response domain. The purpose of this operator is to achieve a certain
164
Operator: get-boomArguments: sensitive-area1,boom-level1,numerical1,
sea-sector1, latest-end1, numerical2 is (length-boom-ft boom1),sea-state1 is (current-sea-state sea-sector1 latest-end1),boom1 with max-sea-state =greater than sea-state1;
Purpose: (level>= sensitive-area1 boom-level1 numerical1)Instantiate: boom1Precondition: (in-service boom1)Plot:Parallel
Branch 1:Goal: (located boom1 sensitive-area1)Process
Action: locate-deploy-boomArguments: boom1,sensitive-area1,sea-sector1,latest-end1;Effects: (produce sensitive-area1 boom-level1 numerical2)Resources:boom1;
Branch 2:Goal
Goals: (level>= sensitive-area1 boom-level1 numerical1)Arguments: sensitive-area1,boom-level1,numerical1,
sea-sector1,latest-end1;End ParallelEnd Plot End Operator
Figure 18.3: Operator that Accumulates Boom at an Oil Spill
length of boom at a particular sensitive area. Here, three arguments are used in thelevel>= predicate
since the same area may have other levels, e.g., a vacuum level.
This operator picks a particular boom,boom1, that is suitable for the current sea state (checked by
the= greater thanconstraint).Numerical2 is the length of this boom. The plot then deploys this boom
and recursively posts the samelevel>= goal in parallel so that the planner continues to accumulate
booms. (These goals could also have been sequential, if desired.) Branch 1 of the plot posts the goal of
getting the boom to the sensitive area and records the production ofNumerical2 units of boom length
at this area.
Branch 2 of the plot posts the purpose again. This causes the planner to continue accumulating
boom length until the required level is achieved. In particular, this same operator may again be used to
expand the recursive goal. When enough boom length has been accumulated, the planner will change
the recursive goal to a phantom and order it after all the actions that together achieve the given level.
This recursive accumulation requires special treatment. In the general case, a set of actions together
165
make such alevel goal true, i.e., the actionsphantomizethe goal. Thus, several actions that produce
or consume quantities will phantomize such a goal by being ordered before thelevel phantom. The
planner, therefore, removes all such orderings to alevel phantom whenever one is removed, and resets
the phantom to a goal. This is correct since the goal relies on all these orderings to become a phantom.
The replanner also has a special algorithm for accumulation goals (see Section 7.4). When one of
the contributors to an accumulation has a precondition that is no longer true, the replanner removes the
contributor. Thelevel phantom becomes a goal, and its solution should achieve the intended effect.
This algorithm is justified as follows. Of the N actions achieving thelevel goal, some subset M have
their preconditions violated. All M cannot be kept in the plan, since one action may satisfy thelevel
that all M together satisfied before. Instead, SIPE–2 eliminates these M entirely and changes thelevel
phantom back to a goal and solves it.
The variable*parallel-phantomize-by-addition* described in Section 15.1.4 controls
the phantomization of accumulation goals and can be set using thePlanningcommand in the Profile
menu.
18.6 Temporal Reasoning
By itself, SIPE–2’s temporal reasoning capability is primitive, but SIPE–2 has been extended to cooper-
ate with General Electric’s Tachyon system for temporal reasoning. Another temporal reasoning system
can be used by replacing the functions that write the Tachyon output and read the Tachyon input. How-
ever, Tachyon assumes each node has a non-zero duration, so SIPE–2 has included that assumption (this
would not be difficult to change). This section describes how temporal reasoning can be done both with
and without Tachyon. The problem is to constrain the start-times, end-times and durations of actions
appropriately so that a good schedule (i.e., assignment of start-times) can be produced. The numerical
value for time in SIPE–2 can be a list of numbers customized for the problem. For example, time can
be represented as(days hours minutes seconds) .
Temporal constraints are specified in SIPE–2 operators in three ways. First, the plot specification
implicitly defines ordering constraints between plot nodes. In terms of Allen relations, a plot node
has the relationshipbefore or meets with its successor plot node. A second method of adding
temporal constraints in an operator is to use theconstraintsslot. This slot allows specification of any
of the thirteen Allen relations between any two nodes in the plot of the operator. The syntax is given in
Section D.3.
Third, all variable names in an operator composed by adding an integer to one of the distinguished
classes in Figure 18.4 represent a temporal constraint on any plot node on which they appear. For
example, if the variable nameearliest-start.2 occurs on the fifth plot node, it will constrain the
plan node created from this plot node to have the given earliest start time. (If more than one variable of
166
Temporal Aspect Distinguished Classes
start-time earliest-start latest-start start-timeend-time earliest-end latest-end end-timeduration shortest-duration longest-duration duration
Figure 18.4: Classes for Variable Names Specifying Temporal Constraints
such a class is present, only the first is used.) The value ofearliest-start.2 can be relative to an
argument of the goal that is being expanded by the operator. Figure 18.3 shows an example of the use of
a latest-end variable to constrain the ending time of an action. The non-modified classes in Figure 18.4
(start-time end-time duration ) are used to specify the exact time when intervals are not
needed. For example, start-time specifies both the earliest-start and the latest-start which are equal.
Constraints from variable names are fully satisfied only when Tachyon is used (although setting the
variable*use-arg-time-windows* to T will cause the critics to use such constraints even when
Tachyon is disabled).
18.6.1 Initializing temporal reasoning
By default, temporal reasoning is disabled. It can be enabled and disabled with the following functions.
enable-temporal-reasoning &key (tachyon t) (merge t) (generate t) [Function]
This function is called when loading domain files for a domain that uses temporal reasoning. It shouldbe called before any operators or the sort hierarchy are defined as it defines temporal classes. Thekeywords give the values for three of the global variables described in the next section.Tachyonprovides the value for*use-tachyon* (nil T :before :after ). Merge provides theboolean value formerge-final-time-sources , andgenerate provides the boolean value for*generate-interval-constraints* .
disable-temporal-reasoning [Function]
This function disables temporal reasoning by rsetting several global variables to their default values.
When temporal reasoning has been enabled, the classtime-tuple is defined. The parser treats
variables in this class as a type of “macro” that expands to the 6-tuple of variables commonly used by
temporal reasoning systems. In particular, the variable nametime-tuple.N (where N is any integer)
will be expanded by the parser into:
earliest-start.N latest-start.N earliest-end.N latest-end.Nshortest-duration.N longest-duration.N
167
These time-tuple variables can occur in the arguments list of an operator or plot node, in the argu-
ments of a predicate, or in the arguments of a function constraint. Iftime-tuple.1 appears in the
arguments of an operator, then the rest of the operator can refer to variablesearliest-start.1 and
shortest-duration.1 (for example) and place constraints on them.
For example, writing(pump-oil pump.1 time-tuple.1) as a goal or effect predicate
would expand to the following predicate before translation to the internal representation:
(pump-oil pump.1 earliest-start.1 latest-start.1earliest-end.1 latest-end.1shortest-duration.1 longest-duration.1)
18.6.2 Temporal reasoning with Tachyon
The SIPE-Tachyon interface was completely rewritten in version 4.11 of SIPE–2. SIPE–2 now more
generally and accurately translates its time constraints to Tachyon, and supports the latest (1996) version
of Tachyon which requires a different syntax. SIPE–2 also make use of new Tachyon features regarding
hierarchical nodes, but such uses are not described in this document. SIPE–2 now lays out its Tachyon
networks so that the plan displays nicely in the Tachyon GUI for easy debugging and viewing.
To use Tachyon for temporal reasoning, the user must have a licensed copy of Tachyon. Temporal
constraints in SIPE–2 are written to a file that is read by Tachyon. Tachyon processes these constraints
and writes a file of narrowed time windows for the start-times, end-times, and durations of all the actions.
This file is used to update the SIPE–2 plan and planning continues. Currently this is done once or twice
per planning level, when the plan critics are applied.
The following variables control the use of Tachyon in SIPE–2:
*use-tachyon* [Variable]If this variable isNIL (the default),SIPE–2 does not call Tachyon or write files for it. If this variable isT, the planner calls Tachyon both before and after the plan critics are applied. If this variable is:before , then Tachyon is called before application of the plan critics, but not after. Similarly, a valueof :after means Tachyon is called after the critics, but not before.
*tachyon-output-path* [Variable]Files are written for Tachyon only when this variable is non-nil. The files are written to the pathnamethat is the value of this variable. The default is “arpi:bin;”. The user should have read/writepermission in this directory.
skip-tachyon-time-windows [Variable]Tachyon sometimes cannot recognize its own solution to temporal constratins as a solution. (TheTachyon implementors said this is a rounding error.) If this variable isT (the default is NIL),SIPE–2does not provide Tachyon with the narrowed time windows that Tachyon previously returned. Instead,only the constraints generted by the planner are sent. This variable should be set toT if Tachyon findsconstraints inconsistent that if previously determined were consistent.
168
merge-final-time-sources [Variable]If this variable is non-nil (the default), thenSIPE–2 merges the planner-generated constraints and theTachyon constraints for any time window that is not instantiated in the final plan. If this variable isNIL , the planner-generated time windows are left intact for time windows that are not instantiated.
*tachyon-3-display-edges* [Variable]If this variable is 1 (the default), edges are not displayed in the Tachyon GUI. A value of 2 causesTachyon to display edges as it solve the network.
*tachyon-format* [Variable]This variable specifies the units used by Tachyon. Use 1 for minutes, 2 for hours, and 3 for days (thedefault).
When drawing and printing plans, SIPE–2 prints the time intervals for the start-time, end-time, and
duration of each node as computed by Tachyon. During the interactive search, the user must cause the
plan to be redrawn after Tachyon is called in order to see the new time windows.
As with other critics, there is a tradeoff involved in deciding how often to call Tachyon. Frequent
calls take time, but infrequent calls may miss opportunities to tighten constraints and make good plan-
ning decisions. The functionupdate-tr-constraints can be called to update the temporal con-
straints at any time. SIPE–2 calls this function at the end of each planning level. Calling Tachyon
before the plan critics can be useful for two reasons: (1) the propagated time windows from Tachyon
may eliminate some possible conflicts thus simplifying the application of the other critics, or (2) the
time windows may provide information useful for choosing the best way to handle a conflict. However,
if neither of these occurs in a given domain, it is best to just apply Tachyon after the plan critics.
If Tachyon is called before the critics, it may or may not be necessary to call it again after the critics,
depending on the properties of the problem domain. If the plan critics add ordering links or instantiations
that significantly affect the time windows, then much information can be gained by calling Tachyon a
second time each level. However, calls to Tachyon can be time consuming.
The constraints given to Tachyon consist of all the ordering links, all the arguments to actions that are
in the distinguished classes in Figure 18.4, any additional constraints encoded in theconstraintsslot of
an operator (which are transferred to plan nodes during operator application), and time windows returned
by a previous call to Tachyon. Tachyon returns narrowed time windows for each of the arguments that
satisfy all the constraints.
All plan critics use the Tachyon time windows when modifying the plan. New orderings induced
by the Tachyon time windows must be added as an ordering link to be properly processed by the truth
criterion. Tachyon plans to return to SIPE–2 a list of new orderings, but this has not yet been done.
Figure 18.5 shows an operator that uses distinguished Tachyon variables and posts temporal con-
straints between actions in its plot. The start-time of the mobilize action and the end-time of the final
169
action are constrained by values in the goal being solved, and the firstoverlaps constraint requires
that the first two unordered actions for moving on the ground must overlap in time.
18.6.3 Temporal reasoning with Duration as Uncertainty
As of version 4.15 in mid-1997, SIPE–2 also provides a capability to do temporal reasoning with differ-
ent assumptions that those built into Tachyon. In Tachyon’s approach, either duration or start-time has
to be chooseable by the executor at execution time. When duration is a range, Tachyon assumes that the
constraints are satisfiable if some value in that range satsifies the constraints.
If Tachyon’s assumptions are desired, then using Tachyon is preferred for complex temporal rea-
soning. A complex scheme was used in SIPE–2 before Tachyon was integrated, but has not been used
since. It does not support all Allen temporal relations. Time is treated as a consumable resource that
can be consumed but not produced, and whose consumption over parallel tasks is nonadditive [8, 9].
Operators can use the distinguished classes in Figure 18.4 to specify temporal variables with numerical
constraints on them that are satisfied by the planner. In particular, a variable can be constrained to be
the value computed by a Lisp function which is generally how durations are computed. Temporal rea-
soning without Tachyon has drawbacks that limit its use to domains without much interaction between
unordered actions. Therefore, the details are no longer described in this manual.
SIPE–2 now provides the option we callduration-as-uncertainty, where the duration interval is
considered to be uncertainty in how long the action will take to execute. Therefore, the plan must work
for any number in the interval from shortest-duration to longest-duration. This option is invoked with
the following variable:
*duration-as-uncertainty* [Variable]The value of this variable must beNIL (the default) to use Tachyon, andT for using duration asuncertainty.
Using this option, SIPE–2 automatically adds the following hard constraints to individual actionswith temporal variables:
earliest-end is (sipe+ earliest-start shortest-duration)latest-end is (sipe+ latest-start longest-duration)
earliest-start is (sipe- earliest-end shortest-duration)latest-start is (sipe- latest-end longest-duration)
shortest-duration is (sipe- earliest-end earliest-start)longest-duration is (sipe- latest-end latest-start)
170
Operator: Deploy-airforceArguments: airforce1,airfield2,end-time1,
start-time1 is (rld airforce1), location1,airfield1 is not airfield2,cargobyair1,cargobysea1,seaport1, seaport2 is not seaport1,sea-loc1,air-loc1;
Purpose: (deployed airforce1 airfield2 end-time1)Precondition: (at airforce1 location1)
(near airfield1 location1) (near seaport1 location1)(partition-force airforce1 cargobyair1 cargobysea1)(transit-approval airfield2)(transit-approval seaport2)(near seaport2 airfield2)(route-aloc airfield1 airfield2 air-loc1)(route-sloc seaport1 seaport2 sea-loc1)
Constraints:(overlaps (ground-moved . 1) (ground-moved . 2))(overlaps (moved . 1) (moved . 2))
Plot:Process
Action: mobilizeArguments: airforce1,location1,start-time1,cargobyair1, cargobysea1;Effects: (mobilized airforce1 location1)
(at cargobyair1 location1) (at cargobysea1 location1)Parallel
Branch 1:Goal: (ground-moved cargobyair1 airfield1)Goal: (moved cargobyair1 airfield2)
Branch 2:Goal: (ground-moved cargobysea1 seaport1)Goal: (moved cargobysea1 seaport1)Goal: (ground-moved cargobysea1 airfield2)
End ParallelProcess
Action: join-aggregateArguments: airforce1,airfield2,cargobyair1,cargobysea1,end-time1;Effects: (at airforce1 airfield2)
(not (at cargobyair1 airfield2)) (not (at cargobysea1 airfield2))End Plot End Operator
Figure 18.5: Sipe Operator with Tachyon Temporal Constraints
171
Operator: transport-craft-to-beachArguments: craft1,beach1,
earliest-start1, latest-start1, earliest-end1, latest-end1,shortest-duration1 is (shortest-water-transport-duration
craft1 beach-approach1longest-duration1 is (longest-water-transport-duration
craft1 beach-approach1 beach1),beach-approach1, military-unit1, attack-helo1;
Preconditions:(adjacent-regions beach1 beach-approach1)(at-location craft1 beach-approach1)(helo-escorting attack-helo1 craft1)
Purpose: (craft-transported-to craft1 beach1earliest-start1 latest-start1 earliest-end1 latest-end1shortest-duration1 longest-duration1)
Plot:Goal: (approach-to-beach-cleared beach1 military-unit1)Process
Action: transport-craftArguments: craft1, beach1, beach-approach1,
earliest-start1, latest-start1, earliest-end1,latest-end1, shortest-duration1, longest-duration1;
Effects: (at-location craft1 beach1)(not (at-location craft1 beach-approach1))
End Plot End Operator
Figure 18.6: Sipe Operator using Duration-as-Uncertainty
The temporal variables are specified by using the distinguished classes in Figure 18.4 as argumentsto operators. If a variable in classduration is present, then it represents both shortest-duration andlongest-duration (which are thus equal). A variable in classstart-time can be used in place ofboth earliest-start and latest-start variables, and similarly forend-time . Each plot node in an operatorshould have only one variable from any one temporal class in its arguments. Figure 18.6 is an exampleof an operator using duration-as-uncertainty temporal reasoning.
The above constraints are not consistentwith Tachyon, and only the first two are the same as Tachyon
constraints. They are used only when SIPE–2 is doing the temporal reasoning without Tachyon, as
directed by the following variables.
*duration-as-uncertainty* [Variable]The value of this variable must beNIL (the default) to use Tachyon, andT for using duration asuncertainty.
172
Which of the above 6 constraints are generated is controlled by the following two variables. The
first controls which of the 3 pairs are generated, and the second controls whether the first member of a
pair, the second member of a pair, or both are generated.
*generate-interval-constraints* [Variable]This variable controls the automatic generation of arithmetic constraints on temporal variables inoperators when they are first parsed. The default value isNIL , which is generally used for Tachyon.However, the value can be one of:start :end :duration while using Tachyon, in which casethe specified pair of temporal constraints become hard constraints in the operator. When usingduration-as-uncertainty, the value can still be such a singleton, or it can be a list of any subset of thesethree values. Generally, all three are used.
*generate-earliest* [Variable]The value of this variable should be one of:both :earliest :latest , with :both being thedefault. This variable applies only to constraints generated automatically as directed by the previousvariable.
For Tachyon, only one of the 3 options:start :end :duration can be selected, or Tachyon
will fail, in general. You cannot have all these constraints, as the relationships change depending on
which direction you compute. Given start and duration, Tachyon will compute end. Given duration and
end, it will compute start. With duration-as-uncertainty, all six constraints are consistent. For Tachyon,
we assume the desired constraints are a global property (e.g., you forward chain time or backward chain
on time) of all operators. If this is not true, the user must write the temporal constraints instead of having
them generated automatically.
173
Bibliography
[1] P.D. Karp, J.D. Lowrance, T.M. Strat, and D.E. Wilkins. The Grasper-CL graph managementsystem.LISP and Symbolic Computation, 7:245–282, 1994.
[2] Peter D. Karp, John D. Lowrance, and Thomas M. Strat.The Grasper-CL Documentation Set,Version 1.1. SRI International Artificial Intelligence Center, Menlo Park, CA, 1992.
[3] P. B. Ladkin. Primitives and units for time specification. InProc. of the 1986 National Conferenceon Artificial Intelligence, pages 354–359, American Association for Artificial Intelligence, MenloPark, CA, 1986.
[4] Karen L. Myers. Strategic advice for hierarchical planners. In L. C. Aiello, J. Doyle, and S. C.Shapiro, editors,Principles of Knowledge Representation and Reasoning: Proceedings of the FifthInternational Conference (KR ’96). Morgan Kaufmann Publishers, 1996.
[5] Karen L. Myers.User Guide for the Advisable Planner. Artificial Intelligence Center, SRI Inter-national, Menlo Park, CA, version 1.0 edition, October 1996.
[6] Karen L. Myers and David E. Wilkins.The Act-Editor User’s Guide: A Manual for Version 2.2.Artificial Intelligence Center, SRI International, Menlo Park, CA, September 1997.
[7] Karen L. Myers and David E. Wilkins. Reasoning about locations in theory and practice.Compu-tational Intelligence, 14(2):151–187, 1998.
[8] David E. Wilkins. Practical Planning: Extending the Classical AI Planning Paradigm. MorganKaufmann Publishers Inc., San Francisco, CA, 1988.
[9] David E. Wilkins. Can AI planners solve practical problems?Computational Intelligence,6(4):232–246, 1990.
[10] David E. Wilkins and Karen L. Myers. A common knowledge representation for plan generationand reactive execution.Journal of Logic and Computation, 5(6):731–761, December 1995.
[11] David E. Wilkins, Karen L. Myers, John D. Lowrance, and Leonard P. Wesley. Planning andreacting in uncertain and dynamic environments.Journal of Experimental and Theoretical AI,7(1):197–227, 1995.
174
Appendix A
SIPE-2 Input for the Blocks World
Here we present the actual input for the blocks world. This input is distributed with SIPE–2 in the filesipe/input/blocks.sipe .
There is another file in the distribution,sipe/input/blocks-fuel.sipe , which extends theblocks world as a test domain for numerical capabilities of SIPE–2. It is a blocks world where moving ablock uses up units of fuel as a function of the size of the block. There are extraneous operators to showuse of syntax. In PROB1 the robot must move some block other than A onto B and have fuel remainingin the range of [5, 50]. Thus, it must first move A off B. To accomplish this, it must move a lightblock onto B and use the more fuel-efficient of the two operators for putting blocks on other blocks.Continuous varptrs are never instantiated, while numerical varptrs will be instantiated to a numericalobject. Thus, the amount of fuel consumed by one particular action is represented by a numerical varptr,while the fuel level of the robot is a continuous varptr.
;This is a SIPE-2 input file for a blocks world where more than one block;can be on top of another block.(in-package :sipe)(define.domain)
CLASS: objectsSUBCLASSES: blocks,supportsEND CLASS
OBJECT: aPARENT-CLASS: blocksPROPERTIES:
COLOR = green, SIZE = 5END OBJECT
CLASS: blocksPARENT-CLASS: objectsSUBCLASSES: redblocks,blueblocksINSTANCES: a,b,c,d,eEND CLASS
175
CLASS: redblocksPARENT-CLASS: blocksINSTANCES: r1,r2END CLASS
CLASS: blueblocksPARENT-CLASS: blocksINSTANCES: b1,b2,b3END CLASS
CLASS: supportsPARENT-CLASS: objectsINSTANCES: tableEND CLASSSTOP
(define.domain)PREDICATES:(on a b) (on b table) (on c table) (on d table) (on e table)(on r1 b1) (on b1 table) (on b2 table) (on r2 table) (clear table)END PREDICATES
OPERATOR: puton1ARGUMENTS: block1, object1 is not block1PURPOSE: (on block1 object1)PLOT:
PARALLELBRANCH 1: GOALS: (clear object1)BRANCH 2: GOAL: (clear block1)
END PARALLELPROCESS
ACTION: putonARGUMENTS: block1, object1RESOURCES: block1EFFECTS: (on block1 object1)
END PLOT END OPERATOR;all problems also solved without a RESOURCE declaration
;take one block off the block to be cleared then post the goal againOPERATOR: cleartop-recurseARGUMENTS: object1, object2 is not object1, block1PURPOSE: (clear object1)PRECONDITION: (on block1 object1);; following optional, use for advice (must add . in object2)PROPERTIES: FEATURES = (clearing-block recursive-clear),
ROLES = ((RECEPTOR . object.2))PLOT:
PROCESSACTION: putonARGUMENTS: block1, object2
176
EFFECTS: (on block1 object2)
GOAL: (clear object1)END PLOT END OPERATOR
;following not needed, here to show use of GENERATE-GOALS; and an alternative specification of previous operator.OPERATOR: cleartop-generateARGUMENTS: block2,object2 is not block2, block1PURPOSE: (clear block2);; following optional, use for advicePROPERTIES: FEATURES = (clearing-block generate-clear),
ROLES = ((RECEPTOR . object.2));PLOT:
PROCESSACTION: generate-goalsGOALS: (on block1 object2)PATTERN: (on block1 block2)ARGUMENTS: object2
PROCESSACTION: clearedARGUMENTS: block2EFFECTS: (clear block2)
;;cannot deduce (CLEAR BLOCK2) from any individual action in loop.;(clear block2) will be deduced after the generated goals, but is posted;again so the execution monitor will protect it until purpose achievedEND PLOTEND OPERATOR
;;;; ====================== Deductive operators ==========================
INIT-OPERATOR: DCLEAR-INITARGUMENTS: block1, object1, object3 CLASS EXISTENTIALTRIGGER: (on block1 object1)CONDITION: -(on object3 block1)EFFECTS: (clear block1)END INIT-OPERATOR;deduce clears for initial world for every block that is on something.
STATE-RULE: DCLEARARGUMENTS: object1,object2 CLASS blocks, object3 CLASS EXISTENTIALTRIGGER: -(on object1 object2)CONDITION: -(on object3 object2)EFFECTS: (clear object2)END STATE-RULE;Deduce that a block is CLEAR when you move something from it and there is;no other block on it. This works correctly when N blocks are on top of;another block, deducing clear after no blocks remain on top of OBJECT2.;To force things to move off blocks, insert CLASS BLOCKS after OBJECT2 in
177
;the arguments (see the section on deduction pitfalls).
CAUSAL-RULE: NOTONARGUMENTS: object1,object2,object3TRIGGER: (on object1 object2)PRECONDITION: (on object1 object3)EFFECTS: -(on object1 object3)END CAUSAL-RULE;deduce that the block moved is not on the block it was previously on.;The trigger matches the current effect, but the precondition matches;in the previous state of the world. To allow for blocks being ON more;than one block, one could make OBJECT3 universal.
STATE-RULE: ONCLEARARGUMENTS: object1,block1TRIGGER: (on object1 block1)EFFECTS: -(clear block1)END STATE-RULESTOP
(init.deduce)(DEFINE.PROBLEM)
PROBLEM: PROB2PARALLEL
BRANCH 1: GOAL: (on a b)BRANCH 2: GOAL: (on b c)
END PARALLEL END PROBLEM
PROBLEM: PROB4PARALLELBRANCH 1: GOALS: (on blueblock3 blueblock4)BRANCH 2: GOALS: (on redblock3 redblock4)END PARALLEL END PROBLEM
STOP
;; example use of text descriptions(setq name-flag :text-description args-flag nil)
(setq *ACTION-DOCUMENTATION-STRINGS*’((puton (1 2) "Put ˜A on ˜A")
(puton1 (1 2) "Achieve getting˜% ˜A on ˜A")))(setq *GOAL-DOCUMENTATION-STRINGS*
’((on (2 1 2) "Get ˜A on ˜A")(clear (block) "Clear the top˜% of ˜A")))(setq *DOCUMENTATION-STRINGS*
’((on (2 1 2) "˜A is on ˜A")(clear (block) "˜A is clear")))
178
;Examples of use of advice. (also requires properties on operators)
; Role Advice;This makes good plans in standard problems
(defparameter clear-to-table(create-advice
:polarity T:id :clear-to-table:opr-context ’((clearing-block . T)):arole-id ’receptor:arole-filler ’(IS $x TABLE):text "Move blocks to table when clearing a block"))
;This makes bad plans(defparameter clear-to-E
(create-advice:polarity T:id :clear-to-E:opr-context ’((clearing-block . T)):arole-id ’receptor:arole-filler ’(IS $x E):text "Move blocks to block E when clearing a block"))
; Method advice.(defparameter generate-clear
(create-advice:polarity T:id :generate-clear:opr-context ’((clearing-block . T)):opr-advised ’((generate-clear . T)):text "When clearing a block, use generate-goals"))
(defparameter recursive-clear(create-advice
:polarity T:id :recursive-clear:opr-context ’((clearing-block . T)):opr-advised ’((recursive-clear . T)):text "When clearing a block, use recursive operator"))
;;; Note: a piece of advice must appear in 1+ libraries or it doesn’t;;; appear in the advice UI. This is the library.(defparameter ADVICE-DICTIONARY
(loop for advice-sym in ’(clear-to-table clear-to-Egenerate-clear recursive-clear)
collect (symbol-value advice-sym))"List of all advice that can be selected")
(setf *ADVICE-LIBRARIES* ’(advice-dictionary))
179
Appendix B
SIPE-2 Input for the Missionaries andCannibals Problem
This appendix presents a SIPE–2 input file for the missionaries and cannibals problem. It shows the use
of LEVEL predicates to do numerical reasoning. It is also a good problem for finding multiple solutions
in a search space as the planner finds 4 solutions when told to search the whole space.
(in-package :sipe);AUTHORS: Carla O. Ludlow and Karen M. Alguire and David E. Wilkins
;(setq multiple-answers t);set this if you wish to backtrack to find all 4 solutions to the problem.; to find one solution: 1.6 seconds on Sparc 20.;; Speed things up slightly by disabling some features we don’t use:(setq *DEFAULT-DEPTH-LIMIT* 14) ;extend default depth limit(setq RECHECK-PHAN-DEDUCE nil)(setq *CHECK-PRECONDS-IN-INTERP* nil) (setq PHANTOMIZE-CHOICEPROCESS nil)(setq *RESOURCE-FREQUENCY* 0) (setq *CBG-FREQUENCY* 0)(setq REMOVE-REDUNDANT-ACTIONS-FREQUENCY 0)
(DEFINE.DOMAIN)CLASS: river-banksINSTANCES: left-bank, right-bank END CLASS
CLASS: peopleINSTANCES: cannibals, missionaries END CLASS
CLASS: boatsINSTANCES: two-people-boat END CLASSSTOP
(DEFINE.DOMAIN)static-predicates: (opposite-bank)
PREDICATES:
180
(opposite-bank left-bank right-bank)(opposite-bank right-bank left-bank)(state 3 3 0 0 left-bank);prevent the return to identical states, eg identical return trip
(on two-people-boat left-bank)(level cannibals left-bank 3)(level cannibals right-bank 0)(level missionaries left-bank 3)(level missionaries right-bank 0)END PREDICATESSTOP
(DEFINE.DOMAIN);;==============================OPERATORS==============================;;; These 2 operators instigate trips by (1) ordering of operators;; (prefer 2 people when moving to goal, 1 person on return trips), and;; (2) computing numerical values of state for use in move oprs.
OPERATOR: SEND-TRIP-TO-RIGHTARGUMENTS: continuous1, numerical1 is previous value of continuous1,
continuous2, numerical2 is previous value of continuous2,continuous3, numerical3 is previous value of continuous3,continuous4, numerical4 is previous value of continuous4;
PURPOSE: (move-everybody)PRECONDITION: (on two-people-boat left-bank)
(level cannibals left-bank continuous1)(level cannibals right-bank continuous2)(level missionaries left-bank continuous3)(level missionaries right-bank continuous4);
PLOT:CHOICEPROCESS:
ACTION: move-mc, move-2-c, move-2-m, move-1-c, move-1-m;ARGUMENTS: numerical1,numerical3,numerical2,numerical4,right-bank;EFFECTS: (on two-people-boat right-bank);
GOAL: (move-everybody)END PLOT END OPERATOR
OPERATOR: SEND-TRIP-TO-LEFTARGUMENTS: continuous1, numerical1 is previous value of continuous1,
continuous2, numerical2 is previous value of continuous2,continuous3, numerical3 is previous value of continuous3,continuous4, numerical4 is previous value of continuous4;
PURPOSE: (move-everybody);PRECONDITION: (on two-people-boat right-bank)
(level cannibals left-bank continuous1)(level cannibals right-bank continuous2)(level missionaries left-bank continuous3)(level missionaries right-bank continuous4);
PLOT:CHOICEPROCESS:
181
ACTION: end-mc, move-1-m, move-1-c, move-mc, move-2-c, move-2-m;ARGUMENTS: numerical2,numerical4,numerical1,numerical3,left-bank;EFFECTS: (on two-people-boat left-bank);
GOAL: (move-everybody)END PLOT END OPERATOR
OPERATOR: END-MCARGUMENTS: numerical1, numerical2, numerical3, numerical4, river-bank1;PRECONDITION: (level missionaries left-bank 0)
(level cannibals left-bank 0);PLOT:
PROCESS ACTION: no-human-stewEFFECTS: (move-everybody);
END PLOT END OPERATOR
;;================================= Move Operators =================
OPERATOR: MOVE-MCARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1,
numerical5 is (sipe+ 1 numerical1),numerical6 is (sipe+ 1 numerical2),numerical7 is (sipe+ -1 numerical3),numerical8 is (sipe+ -1 numerical4), river-bank2;
PRECONDITION: (opposite-bank river-bank1 river-bank2)(not (state numerical5 numerical6 numerical7 numerical8 river-bank1))(level>= cannibals river-bank2 1)(level>= missionaries river-bank2 1)(or (level missionaries river-bank2 1)
(level<= numerical7 numerical8))(level<= numerical5 numerical6);
PLOT:PROCESS
ACTION: row-mcARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1;EFFECTS: (on two-people-boat river-bank1)
(produce cannibals river-bank1 1)(produce missionaries river-bank1 1)(state numerical5 numerical6 numerical7 numerical8 river-bank1)
END PLOT END OPERATOR
OPERATOR: MOVE-2-CARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1,
numerical5 is (sipe+ -2 numerical3),numerical6 is (sipe+ 2 numerical1),numerical7 is (sipe+ 0 numerical4),numerical8 is (sipe+ 0 numerical2), river-bank2 ;
PRECONDITION: (opposite-bank river-bank1 river-bank2)(not (state numerical6 numerical8 numerical5 numerical7 river-bank1))(level>= cannibals river-bank2 2)(or (level missionaries river-bank1 0)
(level>= missionaries river-bank1 numerical6));
182
PLOT:PROCESS
ACTION: row-2-cARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1;EFFECTS: (on two-people-boat river-bank1)
(produce cannibals river-bank1 2)(state numerical6 numerical8 numerical5 numerical7 river-bank1);
END PLOT END OPERATOR
OPERATOR: MOVE-1-CARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1,
numerical5 is (sipe+ -1 numerical3),numerical6 is (sipe+ 1 numerical1),numerical7 is (sipe+ 0 numerical4),numerical8 is (sipe+ 0 numerical2),river-bank2;
PRECONDITION: (opposite-bank river-bank1 river-bank2)(not (state numerical6 numerical8 numerical5 numerical7 river-bank1))(level>= cannibals river-bank2 1)(or (level missionaries river-bank1 0)
(level>= missionaries river-bank1 numerical6));PLOT:
PROCESSACTION: row-1-cARGUMENTS: numerical3, numerical4 ,numerical1, numerical2, river-bank1;EFFECTS: (on two-people-boat river-bank1)
(produce cannibals river-bank1 1)(state numerical6 numerical8 numerical5 numerical7 river-bank1);
END PLOT END OPERATOR
OPERATOR: MOVE-2-MARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1,
numerical5 is (sipe+ -2 numerical4),numerical6 is (sipe+ 2 numerical2),numerical7 is (sipe+ 0 Numerical3),numerical8 is (sipe+ 0 numerical1), river-bank2 ;
PRECONDITION: (opposite-bank river-bank1 river-bank2)(not (state numerical8 numerical6 numerical7 numerical5 river-bank1))(level>= missionaries river-bank2 2)(or (level missionaries river-bank2 2)
(level<= cannibals river-bank2 numerical5)),(level<= cannibals river-bank1 numerical6);
PLOT:PROCESS
ACTION: row-2-mARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1;EFFECTS: (on two-people-boat river-bank1)
(produce missionaries river-bank1 2)(state numerical8 numerical6 numerical7 numerical5 river-bank1);
END PLOT END OPERATOR
OPERATOR: MOVE-1-M
183
ARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1,numerical5 is (sipe+ -1 numerical4),numerical6 is (sipe+ 1 numerical2),numerical7 is (sipe+ 0 numerical3),numerical8 is (sipe+ 0 numerical1), river-bank2;
PRECONDITION: (opposite-bank river-bank1 river-bank2)(not (state numerical8 numerical6 numerical7 numerical5 river-bank1))(level>= missionaries river-bank2 1)(or (level missionaries river-bank2 1)
(level<= cannibals river-bank2 numerical5)),(level<= cannibals river-bank1 numerical6);
PLOT:PROCESS
ACTION: row-1-mARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1;EFFECTS: (on two-people-boat river-bank1)
(produce missionaries river-bank1 1)(state numerical8 numerical6 numerical7 numerical5 river-bank1)
END PLOT END OPERATOR
;;========================== Causal Theory ============================
CAUSAL-RULE: ON-BANK-NOT-ON-OTHER-BANKARGUMENTS: boat1, river-bank1, river-bank2;TRIGGER: (on boat1 river-bank1);PRECONDITION: (on boat1 river-bank2)
(opposite-bank river-bank1 river-bank2);EFFECTS: (not (on boat1 river-bank2));END CAUSAL-RULE
CAUSAL-RULE: PRODUCE-AND-CONSUME-CANNIBALSARGUMENTS: cannibals, river-bank1, numerical3, river-bank2;TRIGGER: (produce cannibals river-bank1 numerical3);PRECONDITION: (opposite-bank river-bank1 river-bank2)EFFECTS: (consume cannibals river-bank2 numerical3);END CAUSAL-RULE
CAUSAL-RULE: PRODUCE-AND-CONSUME-MISSIONARYSARGUMENTS: missionaries, river-bank1, numerical3, river-bank2;TRIGGER: (produce missionaries river-bank1 numerical3);PRECONDITION: (opposite-bank river-bank1 river-bank2)EFFECTS: (consume missionaries river-bank2 numerical3);END CAUSAL-RULESTOP
(DEFINE.PROBLEM)PROBLEM: mc3-a
Goal: (move-everybody)END PROBLEMSTOP
184
;; Define some DOCUMENTATION STRINGS for text descriptions
(setq name-flag :text-description args-flag nil)
(setq *ACTION-DOCUMENTATION-STRINGS*’((row-1-m (5) "Row 1 missionary˜% to ˜A")
(row-2-m (5) "Row 2 missionaries˜% to ˜A")(row-2-c (5) "Row 2 cannibals˜% to ˜A")(row-1-c (5) "Row 1 cannibal˜% to ˜A")(row-mc (5) "Row 1 cannibal and 1 missionary˜% to ˜A") ))
(setq *DOCUMENTATION-STRINGS*’((move-everybody nil
"Move everybody on the left-bank˜% to the right-bank")))
185
Appendix C
SIPE-2 Input for the Mobile Robot World
This appendix describes a SIPE–2 mobile-robot world. The input files for this world can be found in
the SIPE–2 distribution in the directorysipe/input/robot/ . This domain makes heavy use of
conditional (deduced) effects of actions.
The world consists of EK Lobby, J-wing hall, J-wing conference room, Imagen room, and Kurt and
Leslie’s offices. These objects are shown in Figure C.1; the conference room is on the left, and the
three rooms on the right are the Imagen room, Kurt’s office, and Leslie’s office (from top to bottom). A
typical task is to deliver an object to a particular location or person.
The objects in the world are described in the sort hierarchy where AREAs consist of ROOMs,
HALLs, and LOBBYs. They connect to each other through BORDERs which are DOORs or imaginary
borders. Halls are singled out because they have a special place in navigating from room to room. At
the lowest level are locations. They contain actual x,y coordinates for their domain, range, and focus.
These translate directly into numerical arguments for robot commands. There are 32 locations used in
this world: 12 are in the conference room, 6 in the hall, 6 for doors, 4 in the Imagen room, etc.
C.1 Robot Ontology and Predicates
The predicates we have chosen to represent this domain are briefly described. The following predicates
are static and never change value as actions are performed.
(CONNECT BORDER AREA AREA) These predicates are given initially (commutes are deduced)and tell for each door which two rooms it connects. Used to plan paths at room level.
(ADJACENT AREA AREA) These predicates are all deduced from connections and are used forroom-level path planning.
(ADJ LOCATION LOCATION) These predicates are given for all adjacent locations where neitherhas anything AT them (in which case ADJ can be deduced from ADJ-LOC). Commutes are alsodeduced. Used for path planning at lowest level. Note that most of them are deduced.
186
(MAILBOX HUMAN OBJECT) These predicates are all given initially and are used toaccomplishDELIVER actions.
(ONPATH LOCATION LOCATION LOCATION) These predicates give intermediate locations be-tween two nonadjacent locations. Used for path planning. Commutes are deduced.
(DOOR-LOC BORDER AREA LOCATION) All DOOR-LOCs are deduced whenever appropriateINROOM or ADJ-LOC predicates are added. They tell which location in each room is next to thegiven door and are used in planning to go through a door.
The following predicates do change as actions are performed.
(AT OBJECT LOCATION) Most ATs must be given except that every object ON something has itsAT deduced. AT is used during planning to know locations at the lowest level. Many other thingsare deduced from AT so AT is the central predicate at lowest level.
(ADJ-LOC OBJECT LOCATION) These predicates are given initially for all objects not ON includ-ing doors (ONs are deduced). They tell which locations an object is adjacent to and are used forgetting next to objects. During planning these are deduced from ATs.
(INROOM OBJECT AREA) Most initial INROOM predicates are deduced. Every object that is ONsomething has INROOM deduced. INROOMs are deduced for all locations next to objects inrooms (not doors), and locations where objects are AT. Thus an unoccupied location not next toany object must give its INROOM, this happens primarily in halls.
(CONTAINS LOCATION AREA) These predicates are deduced initially for locations that are ADJ-LOC to an object or ones which have an object at them. (Most are deduced.) They are used tocoordinate levels of abstraction, and are therefore posted for uninstantiated LOCATION variableswhen we know their room without knowing their instantiation.
(OPEN BORDER) These predicates are given initially for borders, and are used to make sure theborders are not closed.
(ON OBJECT SUPPORT) These predicates are given initially and trigger many deductions. They areused for noting that an object is on some support which determines its location and adjacencies.
(CLEAR LOCATION) (CLEAR BORDER) These predicates are all given intially, and tell if a loca-tion is clear enough to navigate through with the robot.
187
Figure C.1: Map of Robot World
188
Appendix D
SIPE-2 Input Syntax
This appendix documents the SIPE–2 input syntax. It has not been verified, and the SIPE–2 language
frequently changes. The Backus-Naur Form was originally written by Donald H. Mitchell, although
David E. Wilkins has made extensive revisions and additions.
For those unfamiliar with Backus-Naur Form (BNF), the form on the left of the::= symbol should
be written using the form on the right. Items in the typewriter font (e.g.,item ) represent the exact
characters to use, items in italics (e.g.,op-name) are place-holders representing any symbol, except that
numberrepresents any number andsexprepresents any s-expression. Thej symbol represents ‘or’, the� represents any number of repetitions including zero, and the+ represents exactly one occurrence. The
square brackets in normal font are grouping operators. The bracesfg designate optional elements.
In many parts of SIPE–2’s language, the order of slots does not matter but each slot cannot occur
more than once unless otherwise designated. To notate this unordered but restricted frequency, we
follow the convention in Guy Steele’s,Common Lisp, the Language(2nd ed, p. 9), “Double brackets,
[[ and ]], indicate that any number of the alternatives enclosed may be used, and those used may occur
in any order, but each alternative may be used at most once unless followed by a star. For example,p
[[xjy�jz]] q”
D.1 General Syntax, Comments, Punctuation, etc.
Definition blocksare blocks that start with a keyword and end with the expressionend keyword. Exam-
ples of keywords that start definition blocks include:class object operator state-rule
causal-rule . In a SIPE–2 input file, any Lisp expression may be included anywhere except within
a definition block. Such expressions are evaluated during loading.
In SIPE–2’s language, colons (:) and semicolons (;) are always optional. Use them to make a file
more readable. We suggest putting colons aftereach slot name as in the examples in the appendices.
189
Any pair of slot name followed by a slot value must be terminated either by a semicolon or an atom that
is asipe-input-keyword . Thus, semicolons are optional in correct syntax, but may be used for
stylistic reasons and better syntax-error detection. For example, lists often have their elements separated
by commas and the list ended by a semicolon. Commas that separate list items are required for lists of
atoms (e.g., variable names with constraints), and optional for lists of lists (e.g., predicates).
Note that the parser may not object to lists in certain slots but the planner may not do what is
intended with them. For example, if a goal node is given a list of predicates in itsGoals slot, the parser
will not complain, but the planner will achieve the first goal only.
In an input file, regular Lisp comments that start with semicolons (;) and go to the end of the line
are allowed anywhere Lisp expressions are and anywhere that the semicolon is the first nonwhitespace
character on a line. Semicolons that are not the first nonwhitespace character will be interpreted as part
of the syntax.Properties andcomment slots can be specified for operators, plan nodes, problem
nodes, sort hierarchy nodes, and plot nodes. An example of the syntax for using these slots in an operator
and its plot is shown in Figure 11.1.
D.2 Domain, Predicate, and Problem Definitions
define.domain [Function]
This function starts SIPE–2’s parser for reading the sort hierarchy, operator definitions, and world pred-
icates. The parser controls input until it sees the symbolstop at the top level (i.e., not within a defi-
nition). There may be any number ofdefine.domain commands, except that each file must have a
beginningdefine.domain and a correspondingstop . Any input so surrounded may be in a separate
file, but the description of the sort hierarchy must be loaded first.
define.problem [Function]
This function starts SIPE–2’s parser for reading problem definitions. The parser controls input until it
sees the symbolstop at the top level. Any number ofdefine.problem commands can be used.
Problem definitions can be loaded at any time after the sort hierarchy. It can be useful to have a file with
only problem definitions in it so they can be easily edited and loaded.Define.problem can even be
called interactively from a Lisp listener and the input typed to the system, provided that no colons or
semicolons are used (SIPE–2’s readtable is not used). However, errors are much easier to correct in a
file.
190
The syntax for top-level declarations and definitions is
domain ::= (define.domain) domain.def� stop
problem.def ::= (define.problem) problem� stop
domain.def ::= operator.def� j sort.hier� j fpred-declsg predicates� j sexp�
problem ::= problem prob-namef;g plot end problem
pred-decls ::= [[ static-decl� j open-decl� j closed-decl� j function-decl� ]]
static-decl ::= static-predicates ( pred-name� )
open-decl ::= open-predicates [( pred-name� ) j t ]
closed-decl ::= closed-predicates ( pred-name� )
function-decl ::= no-range-functions ( fun-name� )
predicates ::= [[ predicates predlistend predicates j
additions predlistend additions j
initial-additions predlistend intiial-additions ]]
predicates [Keyword]
This keyword indicates the predicates following it will be placed in a newly created world.
additions [Keyword]
This keyword indicates the predicates following it will be added to an existing world.
static-predicates [Keyword]
This keyword is followed by a list of predicate names and declares them as static.
open-predicates [Keyword]
This keyword is followed byt or a list of predicate names and declares them as open predicates. A valueof t makes all predicates be open by default; closed predicates must then be declared as exceptions.
closed-predicates [Keyword]
This keyword is followed by a list of predicate names and declares them as closed predicates. It is notneeded unless an “open-predicates t” declaration has been made.
stop [Keyword]
This keyword signals the end of adefine.domain or define.problem section.
191
D.3 Operator Definitions
There are two primary types of operators: deductive rules and operators. There are three types of
deductive rules: state, causal, and initial-state. In addition, a deductive rule can be declared as both
an initial-state and state rule. The syntax for pred-arg, args, resources, and instantiate is defined in
Section D.5. The documentation for plot nodes is described in detail in Chapter 14.
The syntax for operators is
operator.def ::= [real-opj rule j causal-rule]
real-op ::= operator op-namef;g args[[ resourcesj instantiatej purposej
preconditionj t-constr-slotj prop-com]] fplotg end operatorrule ::= rule-typeop-namef;g args[[ triggerj effectsj conditionj
prop-com]] end rule-typecausal-rule ::= causal-rule op-namef;g args
[[ triggerj effectsj conditionj preconditionj prop-com]]
end causal-rulerule-type ::= [state-rule j init-operator j init.operator j both.operator ]
trigger ::= trigger predf; g
pattern ::= pattern predf; g
goals ::= goals predf; g
purpose ::= purpose predf; g
precondition ::= [precondition j preconditions ] predlist
condition ::= condition predlist
effects ::= effects predlist
t-constr-slot ::= constraints: ftconstraintg� f; g
predlist ::= predff, g predg f; g
pred ::= f- g( pred-namefpred-argg�) j (not ( pred-namefpred-argg�))
tconstraint ::= ( allen node node) j
( qual-relation( point node) ( point node))
allen ::= starts j overlaps j before j meets j during j
finish j finishes j equals
qual-relation ::= later j later-eq j earlier j earlier-eq j equals
point ::= start j end
node ::= ( node-namef . integerg)
node-name ::= op-namej pred-name
plot ::= plot [copy j plot.step�] end plot
192
plot.step ::= [goal.stepj shortgoal.stepj proc.stepj cproc.stepj par.stepj parexp.stepj
cond.stepj choice.step ]
goal.step ::= fgoal goal.modg goals
shortgoal.step ::= [goal j goals ] predf; g fgoal.modg
goal.mod ::= [[ delay j external-condition j resourcesj sresourcesj argsj protectj
effectsj time j prop-com]]
proc.step ::= process action op-namef; g fproc.modg
parexp.step ::= process action parexpf; g fparexp.modg
cproc.step ::= choiceprocess action op-namef, op-nameg� f; g fproc.modg
parexp ::= [generate-goals j parallel-loop ]
parexp.mod ::= [[ delay j delay-execute j external-condition j args j protect j
goals+ j pattern+ j prop-com]]
proc.mod ::= [[ delay j delay-execute j resourcesj sresourcesj argsj protectj effectsj
time j prop-com]]
par.step ::= parallel fprop-comg branch� end parallel fprop-comg
branch ::= branch numberplot
cond.step ::= cond fprop-comg condbranch� end cond fprop-comg
condbranch ::= condpattern numberpredf; g plot
protect ::= [protect-until j purpose ] [purpose j predlist]
time ::= [[ [start-time j stop-time j duration ] numerical]]
operator op-name [Keyword]
Operators are the actions that SIPE–2 is trying to choose among and order to solve a problem. SIPE–2interns theop-nameand makes it point to the structure designating the operator. Inspect the value ofop-nameto see the internal representation of the operator.
branch number [Keyword]
condpattern number [Keyword]
These keywords declare the beginning of a new parallel or conditional branch. The number followingthem is for readability only. SIPE–2 ignores the number, so it could be anything and there is no need tonumber the branches in any particular order.
copy [Keyword]
Copy directs the system to copy the previous node instead of expanding it.Copy should be the onlystep in the plot since SIPE–2 ignores anything following it.
193
D.4 Sort Hierarchy
sort-hierarchy [Variable]The root class of the sort hierarchy.
SIPE–2 generates a root node which is pointed to by the global variablesort-hierarchy . Any inputclass that has no parent becomes a subclass of the root.
class class-name [Keyword]
Defines the classclass-namein the sort hierarchy. SIPE–2 classes define sets not individuals, i.e. thesystem does not use its class structures as the instantiation of variables or as arguments to a predicate.Classes provide a mechanism for distinguishing the types of individuals and for establishing defaultproperties for whole sets of individuals. SIPE–2 internsclass-namewhich points to the structure desig-nating the class. Thus, one can inspect the value ofclass-nameto see the internal representation of theclass.
object instance-name [Keyword]
Synonyms areinstance andinst . Define the objectinstance-namein the sort hierarchy. SIPE–2internsinstance-namewhich points to the structure designating the instance.
The syntax for the sort hierarchy is
sort.hier ::= class.defj instance.def
class.def ::= class class-name[[ parent.decj subclass.decj instance.decj prop-com]] end
classparent.dec ::= [parent j parent-class ] class-namef; g
subclass.dec ::= subclasses class-namef, class-nameg� f; g
instance.dec ::= [insts j instances ] object-namef, object-nameg� f; g
instance.def ::= ob-tokenobject-name[[parent.decj prop-com]] end ob-token
ob-token ::= [object j instance j inst ]
parent.dec ::= [parent j parent-class ] class-name
194
D.5 Local Variable Definitions
Whenever the parser expects an argument, it can be given a variable name or a literal. Variables and
literals and their naming conventions are described in Section 11.5. The syntax for variables, arguments,
properties, comments, and constraints is—
args ::= arguments arg.deff, arg.defg� f; g
resources ::= resources arg.deff, arg.defg� f; g
sresources ::= [sresources j sharedresources ] arg.deff, arg.defg� f; g
instantiate ::= instantiate arg.deff, arg.defg� f; g
prop-com ::= [[ propertiesj comment]]
properties ::= properties prop.decf, prop.decg� f; g
prop.dec ::= prop-name= sexp
comment ::= comment sexp
pred-arg ::= [literal-argj arg-name]
arg.def ::= [literal-argj named-arg]
literal-arg ::= [object-namej expr-formj numericalj functionj range]
expr-form ::= (expr sexp)
numerical ::= numberj ( number�)
function ::= ( symbol[numericalj symbol]�)
range ::= [ numericalf, g numerical]
named-arg ::= arg-namefconstraintg�
constraint ::= class-conj quant-conj is-conj with-conj with-eqj same-con
class-con ::= [of type j class ] class-name
quant-con ::= class [existential j universal ]
is-con ::= is [is-not j is-currentj numericalj expr-formj function
j rangej object-name]is-not ::= not [[of type class-name] j object-namej ( object-name�) j arg-name]
is-current ::= [current j previous ] value of arg-name
with-eq ::= with prop-namefequal to g [numericalj arg-namej sexp]
with-con ::= with prop-name[greater j =greater j less j =less ] than [nu-
mericalj arg-name]same-con ::= same fasg arg-name
195
Appendix E
Correspondence of SIPE-2 and ACT
Syntax
This appendix briefly describes how an operator or plan in SIPE–2 is translated to ACT. This information
may be useful for an ACT user trying to understand SIPE–2 syntax or a SIPE–2 user trying to use the
Act-Editor.
Advanced concepts:This section assumes knowledge of both systems.
At the top level, both plans and operators must be translated to Acts with environment slots. Ta-
bles E.1 and E.2 show the correspondences for plans and operators, respectively. Note that the compu-
tation of the world predicates on which a plan depends is not currently computed by the Sipe-to-ACT
Translator.
Operator plots are the same as plans for purposes of translation to ACT. Individual plot/plan nodes
are translated to either parallel nodes or conditional nodes in ACT. Any nodes withparallel-links
(see Chapter 16),split nodes, andjoin nodes, must be translated to parallel nodes. Nodes of types
cond , endcond , andcondpattern must be translated to conditional nodes. All other nodes can be
translated to either parallel or conditional nodes. (The Sipe-to-ACT Translator uses conditional nodes.)
Plan Feature ACT Environment Slot
Goals of Problem Achieve Metapredicate in Cue slotAll resources declared in plan Use-Resource slot
World predicates on which plan depends Precondition and Setting slotsProperties Properties slotComment Comment slot
Table E.1: Correspondence of Plans to ACT Slots
196
Operator Slot ACT Environment Slot
Type Class property in Properties slotPurpose Achieve metapredicate in Cue slot
Resources Use-Resource slotArguments/constraints Test metapredicate in Setting Slot, Properties
Precondition Test metapredicate in Precondition slotTime-constraints Time-Constraints property in Properties slot
Instantiate Instantiate property in Properties slotProperties Properties slotComment Comment slot
Table E.2: Correspondence of Operator Slots to ACT
Plot Node Slot Type of Plot Node ACT Metapredicate
Action Process, Choiceprocess Achieve-By metapredicateGoals Goal with External-Condition Wait-Until metapredicateGoals Precondition, Condpattern Test metapredicateGoals Goal, Phantom Achieve metapredicate
Protect-Until all Require-Until metapredicateEffects all Conclude metapredicateDeduce all Conclude metapredicate
Comment all Comment metapredicateProperties all added astuples
Table E.3: Correspondence of Plot Node Slots to ACT
Table E.3 describes how each slot in a plot/plan node is translated to a metapredicate on an ACT plot
node. ACT plot nodes do not have Properties metapredicates, so the properties are added to an internal
data structure namedtuples .
Finally, operators also require translation of constraints on variables. The constraints listed in Sec-
tion 13.2 are all added to either the Setting or Properties slot in the operator’s Act. Table E.4 shows the
correspondence, where lower-case names represent any form of the given type, and upper-case names
represent syntactic keywords. The constraints that translate with an obvious use of the= function (e.g.,
most of the IS constraints) are not included in the table.
197
SIPE-2 Constraint on var ACT Slot Property/Setting Formula
CLASS EXISTENTIAL Properties VARIABLESCLASS UNIVERSAL Properties VARIABLES
CLASS class Setting (CLASS class)OF TYPE class Setting (CLASS class)IS NOT instance Setting (not (= instance))
IS NOT OF TYPE class Setting (NOT (CLASS class))WITH attr value Setting (= (attr var) value)
WITH attr EQUAL TO value Setting (= (attr var) value)WITH attr NOT EQUAL TO value Setting (not (= (attr var) value))
WITH attr GREATER THAN num-val Setting (> (attr var) value)WITH attr LESS THAN num-val Setting (< (attr var) value)
WITH attr =GREATER THAN num-val Setting (>= (attr var) value)WITH attr =LESS THAN num-val Setting (<= (attr var) value)IS CURRENT VALUE OF var1 Setting (= var (current-value var1))IS PREVIOUS VALUE OF var1 Setting (= var (previous-value var1))
Table E.4: Correspondence of Constraints to ACT
198
Appendix F
SIPE-2 Functions and Source Code
This appendix documents many important SIPE–2 functions and indexes the source code. First, top-
level functions for controlling the planner are given. These, together with many functions called by the
GUI, will be the foundation of an API. We have not formally defined an API as yet, but the top-level
functions described below are stable.
NOTE: Functions in this manual with an argument named “plan” take a plan object as the value
of that argument, while those named “context” expect a list of CPPs, and those named “plan-con” can
handle either. The plan object provides the context. Context slots in nodes, such assjcontext and
desc , use actual CPP-lists and not plan objects. The symbols that are context names are bound to the
plan objects (for historical reasons).
The functions for accessing the slots of internal SIPE–2 data structures are of central importance
and are given next. The description of plan and plot nodes refers tovariableswhich arevarptrsin plans
andvardesesin operators and plots. Their internal representation is described in Section 13.3. Predicate
and operator nodes are described after the plan nodes. The value of a slot can be accessed by calling the
slot name as a function on the node. For example,(succ P1267) returns the successor of the node
whose ID is p1267. The ID and TYPE slots occur on every node and structure in the system.
After the sections on data structures, are sections for invoking lower-level algorithms, such as the
critics and truth criterion. These are probably only of interest to people programming a system on top
of SIPE–2.
F.1 Top-Level Functions
Functions described here have been written to support agent-based automatic plan generation, and will
be the foundation of the API.
199
F.1.1 Generating Plans
The API functions for generating plans described here are discussed in Section 3.4.1. The function
generate-plan is called bysolve-act after the Act has been translated to a SIPE–2 problem.
The global variable*act-interactive* can be used to give a global default for themode key-
word in solve-act andgenerate-plan . The mode determines whether plan generation within
these two functions is done interactively, automatically, or in “movie mode”. When planning is auto-
matic,solve is called bygenerate-plan after the problem has been translated to a partial plan (by
initialize-problem ).
*act-interactive* [Variable]This value isT for interactive planning,NIL for automatic planning, and:movie for planning inmovie mode. It supplies a global default for the mode insolve-act andgenerate-plan .
solve-act act &optional return-act &key facts (mode *act-interactive*) (depth-limit*default-depth-limit*) multiple-plans (number-plans 1) partial-plan-at-level time-limit start-time[Function]
Act is an ASCII representation of an Act that represents a task, either an s-expression in Act packageor a string. A plan (or plans) is generated to solve this problem. Ifreturn-act is non-nil, the lastplan generated is translated to an Act, and the name of the Act is returned; otherwise the name of theplan is returned. If a plan cannot be found, NIL is returned. If multiple plans are found, a list of planobjects is in the global varaible*current-plans* .
Facts is a list of predicates that will be added to the initial world before planning.Mode is Tfor interactive planning,NIL for automatic planning, and:movie for planning in movie mode. Thekeywords aftermode apply only to automatic planning and are passed on tosolve .
This function callsgenerate-plan (below), and must be inside the GUI since it uses Grasper —this can be accomplished by running one’s agent from inside the GUI listener window.
generate-plan prob &key facts (mode *act-interactive*) (depth-limit *default-depth-limit*)multiple-plans (number-plans 1) partial-plan-at-level time-limit start-time [Function]
Prob is the name of a SIPE–2 problem to be solved. The return values and keyword arguments are thesame as forsolve-act .
solve-problem problem-name &key plan (depth-limit*default-depth-limit* )(multiple-plansmultiple-answers ) (number-plansnumber-of-answers )partial-plan-at-level (time-limit*time-limit* ) start-time in-progress plan-delayed-goals[Function]
This function callssolve after converting the given named problem to a partial plan suitable forsolve , after copying the problem for future use. The named problem must already be defined inSIPE–2’s internal representation. It is similar togenerate-plan (which is used for servers), exceptfor these differences:
200
� always solves automatically.
� defaults arguments to global variables, rather than arguments preferred for servers.
� allows more types of interactions during automated solving.
� allows 3 extra keywords mentioned below.
� does not set the global variables *act-ph* and *act-context*.
The return values and most keyword arguments are the same as forsolve . Additional keyword argu-
ments arein-progress , a boolean which causes the task network denoted byproblem-name to
be solved immediately with no copy made, andplan-delayed-goals , a boolean which initiates
any delayed planning specified in the generated plan in a background process.
solve node plan &key (depth-limit*default-depth-limit* ) (multiple-plans
multiple-answers ) (number-plansnumber-of-answers ) partial-plan-at-level (time-limit
*time-limit* ) start-time [Function]
This function is the entry point for the automatic search for generating plans.Node is a node in a partial
plan (generally a planhead node).Plan , a plan object, is created initially byinitialize-problem
and must be provided. A plan object from an already expanded plan can be used when continuing
expansion. If starting a new problem, use the functionsolve-problem . Answers are generally
obtained from global variables. Whenmultiple-plans is nil, this function returns the object of the
plan found, orNIL for failure. When searching for multiple plans, this function may return the object
of the last plan found orNIL depending on how the search was terminated, and a list of plan objects for
each plan found are in the global variable*current-plans* , which isNIL on failure. In addition,
the global variables*current-plan* andlastplanhead are set to the plan object and planhead
of the last plan found (with the former beingNIL on failure).
Most of the keyword arguments default to the values of global variables described in Section 3.3.
Depth-limit is an integer – the search will not expand past this many expansion levels.
Multiple-plans determines whether to search for multiple plans and how to name them. If
NIL , only one plan is found. If:gensym-names , multiple plans are found, and a name foreach plan
is generated (planning continues without user interaction). IfT, multiple plans are found, and the user is
queried after each plan for a plan name, whether to display the plan, and whether to continue searching.
Number-plans is an integer orNIL and is only used ifmultiple-plans is non-nil. The
system will stop when this many plans have been found. If the value isNIL , the entire search space will
be explored when multiple plans are requested.
Partial-plan-at-level is an integer orNIL . If integer, the search will stop planning after
that many levels, naming the partial plan and setting it up for interactive planning using the commands
ContinueandContinue-1.
201
Time-limit is a real number in seconds. If more than this many seconds have elapsed, the search
will not start a new level, a backtrack, or start applying a set of operators to a node. The system will
continue applying critics or trying operators on the current node. In highly parallel plans, critics may
take a significant amount of time. Thus, the time limit is too coarse-grained for fractions of a second,
and cannot guarantee returning within a certain time.
Start-time is only used iftime-limit is non-nil. Its value can specify an absolute start time
(using internal-real-time ) from which the time limit should be computed. The default is to
compute the time limit from the time thatsolve is invoked.
initialize-problem problem-name &key automatic [Function]
Problem-name is the name of a SIPE–2 problem to be solved. This function translates it to a partial
plan, suitable forsolve . This involves copying the problem, renaming it, doing deductions, checking
phantoms, and creating a plan object. Ifautomatic is T, the interactive search is not reset, otherwise
it is. The new plan object is returned.
The following function creates problems programmatically and is useful for passing in prob-
lems from remote clients or other systems. Alternatively, Acts can be used to specify problems for
solve-act .
make-problem name plotform &optional world [Function]
Creates a problem with given name, plot, and world. The world defaults to the first member of thelist worlds . The plot form is a list structure version of the SIPE–2 syntax, with no punctuation, thelabels afterend omitted, and a list aroundeach predicate and around eachparallel andcond group.There must be anend for eachparallel andcond group and the end of the problem.
The following variables control drawing in the various planning modes.
automated-planning-display [Variable]This variable specifies whether to draw/print an automatically generated plan. Value is one of:draw:print :neither :use-menu . The default is:use-menu , which asks the user. Use:neither to take no action after plan generation.
automated-replanning-display [Variable]This variable specifies whether to draw/print a newly modified plan. Value is one of:draw :print:neither :use-menu . The default is:neither .
fast-interactive-search [Variable]This variable specifies whether to draw/print after each level of interactive planning. Value is one of:draw :print :neither :use-menu . The default is:use-menu .
202
F.1.2 Loading Files
load-new-file filename [Function]
Loads the given file, but only if it has not already been loaded since SIPE–2 was reset. It also notesthe file as loaded by SIPE–2. For SIPE–2 to notice that a file is loaded, it must be loaded bylfile ,load-new-file , load-and-update , or theInputcommand.
load-and-update filename [Function]
Always loads the given file and notes it as loaded by SIPE–2.
lfile [Function]
Prompts the user for a filename and loads the given file usingload-and-update .
eval-load filename [Function]
This is the recommended function for loading SIPE–2 input files from a top-level input file. It is similarto the Common Lispload function, but some Common Lisp implementations switch the input streamfrom the file to the terminal when expressions read from the input stream are evaluated. This functionloads files without changing the input stream.
F.1.3 Modifying Plans
what-if preds &optional (plan *current-plan*) [Function]
This function takes a set of predicates, adds them to the original world of a plan, then calls the problemrecognizer and replanner to modify the plan to be valid in the new world. Theauto-replan variablecontrols whether the replanning is done in movie mode, interactively or automatically.Preds can bea list of SIPE–2 predicate structures or a list of expressions to parse, e.g.,(not (on a b)) . Thereplanner sets the variables*current-plan* , lastplanhead , and*current-plans* to theresulting plan, see Chapter 7.
F.1.4 Miscellaneous
The following two functions provide useful information that may aid debugging.
find-applicable-operators node plan [Function]
Returns a list of operator names that can be used to solve node. Each operator will help achieve at leastone of the predicates in the goals ofnode. It checks that the arguments of thenodecan be bound to thearguments of the operator.
print-action-for-opr node oprname &optional plan [Function]
203
Prints the entry in the action slot ofnodefor oprname. Prints the expansion produced or an explanationof any failure. If no plan object provided, prints entries for all contexts.
The following functions may not be in the API.
sipe [Function]
Puts up a menu of top-level choices of things to do. Useful when the GUI cannot be accessed The sourcecode gives the function names for invoking top-level modules.
d [Function]
Synonym for displaypkg. If not inside the GUI, it puts up a menu of display choices. If inside the GUI,it will create a second GUI for temporary use. The source code gives the function names for printingdata structures.
The following function is for programmers only.
expand-node operator node plan &optional skip-expan [Function]
This function expandsnodeby applying theoperatorto it, in the context given byplan, a plan object. Ifthere is a valid expansion (either sn existing one or a newly created expansion), the plan-object inplanis returned, but a new CPP has been added to its context for the expansion. If the expansion fails, NILis returned. Ifskip-expanis non-nil, the arguments and preconditions ofoperatorare checked, but noexpansion is done. If the operator was applicable, the plan-object inplan is returned unchanged. Theinteractive planner allows menu-selectable breaking of this function.
F.2 Sort Hierarchy API
The following functions provide read access to the SIPE–2 sort hierarchy. By default, SIPE–2 usesinternal definitions of these functions. However, SIPE–2 includes two file that redefine these APIfuntions. The filehier-gfp.lisp translates each function into GFP function calls. The filehier-aux.lisp uses GFP but short-circuits calls to GFP when possible by directly accessing theinternal sort hierarchy. This API is low-level, in the sense that SIPE–2 uses its own inheritence algo-rithm. A future task is to modify SIPE–2to use a function that accesses a property with inheritence, thenadd such a function to the API.
hierarchy-node-p-api x [Function]
This function is a predicate returning non-nil when X is a node in the sort hierarchy.
properties-api node [Function]
This function returns a list of all the properties of node.
id-api node [Function]
This function returns the name of the node.
204
type-api node [Function]
This function returns the type of the node (class or instance).
subclass-api node [Function]
This function returns a list of classes that are subclasses of node.
instances-api node [Function]
This function returns a list of instances that are direct descendants of node (i.e., not instances of sub-classes).
parent-api node [Function]
This function returns the immediate parent of node.
parent?-api node parent [Function]
This function is a predicate and returns T if parent is a parent (not necessarily immediate) of node.
get-hier-node symbol &optional type [Function]
This function returns the sort hierarchy node with symbol as its name. If type is given, it must be classor instance, and only nodes of that type will be returned.
get-attr-vals attr node [Function]
This function returns the tuple for attr stored on node. (The car of the returned value will be attr.)
For efficiency, SIPE–2 uses the API only when this variable is non-nil.
*use-gkb-sort-hierarchy* [Variable]If this variable isT, the API functions are used for sort hierarchy access.
F.3 Slots on Plan and Plot Nodes
id node [Function]
This is the name of the node. The name is a Lisp pointer to the node.
type node [Function]
Types of control nodes areChoice Dchoice Split Join Cond Endcond . Typesof action/condition nodes are Process Goal Executed Phantom PreconditionChoiceprocess Planhead Condpattern . Control nodes only have the six slots follow-ing immediately below. Choice nodes are inserted automatically whenever SIPE–2 has a choice ofoperators to apply. Choice nodes are copied down as Dchoice nodes to lower planning levels.
succ node [Function]
205
Pointer to the successor of node on the same level. The value is a list of such pointers at split, cond,choice, dchoice, and join nodes. All branches following a split node meet at the same join node, but eachbranch may have different alternative expansions. Thus, a join node has many successors, one for eachpossible combination of alternatives for the parallel branches that came before it. Each node followinga join node has ansjcontext slot whose value is used to choose the successor in the current context.
pred node [Function]
Pointer to the predecessor of node on the same plan level. The value is a list of such pointers at join andendcond nodes.
desc node [Function]
Returns the descendants of node. This is a list of a-ele structures, with one element for each context inwhich an expansion of this node was done. Each a-ele structure has slots start-node and last-node whichpoint to the expansion. The arguments slot saves the variable bindings used during the expansion. Thecontext slot is used to determine which descendant is in the current context, and its value is a list ofCPPs (not a plan object).
ances node [Function]
Pointer to the ancestor of node. The ancestor’s expansion produced node.
sjcontext node [Function]
Value is the minimal context needed to include this node in a plan. The value is a list of CPPs (not aplan object). This is used for traversal of net with respect to context.
mate node [Function]
At control nodes, this slot is filled by a pointer to the node which mates with node (i.e., the matchingjoin of a split, and the matching endcond of a cond).
arguments operator [Function]
This slot is used to declare variables and constraints, and to match an operator to a plan node. Its valueis a list of variables.
resources operator [Function]
This slot is a list of variables, generally a subset ofarguments . It implements the notion of reusableresource — a resource will not be used by two unordered actions.
goals node [Function]
This is a list of predicate nodes that the planner should try to achieve when the goal node is part of aplan. In practice, the list should be of length 1, with additional predicates given in parallel goal nodes(if it is desired that they be achieved in parallel).
206
action node [Function]
This is a list of applicable actions for expanding node. Before any expansions are done, this is a listof the IDs of the operators. Once an operator is applied, the atom is changed to a list where the car isthe operator id and the cdr is a list of a-ele structures, which are also in thedesc slot and point to thedescendants when the operator was applied, and a desription of the failure when the operator was notapplied. The functionprint-action-for-opr uses this information to print the result of applyingan operator to a node.
purpose node [Function]
Returns the protect-until value of node. This is a list of predicate nodes. This is used in executionmonitoring for deciding how long to maintain the main effects of this node.
effects node [Function]
This is a list of predicate nodes (see below) representing the effects of node. When a node is expanded,its effects are copied down to its expansion.
deduce node [Function]
Like effects, but describes effects that have been deduced from deductive rules.
parallel-pred-here node [Function]
parallel-succ-here node [Function]
parallel-pred node [Function]
parallel-succ node [Function]
These functions return the predecessors and successors in parallel branches. Parallel-pred-here andparallel-succ-here have pointers only to nodes at the same hierarchical level as node. Parallel-pred andparallel-succ point to the highest hierarchical level of such a link.
time-constraints node [Function]
This function returns a list of the temporal constraints involving this node. These are given to Tachyon.
properties operator [Function]
This slot is a list of properties. Some properties are written by the system as described in Section 11.2.
comment operator [Function]
This slot is a comment for documentation purposes.
207
F.4 Slots on Predicate Nodes
id node [Function]
This is the name of the node. The name is a Lisp pointer to the node.
type node [Function]
Predicate nodes have atype of PREDICATE.
predname node [Function]
Gives the name of the predicate.
pname node [Function]
Gives the print name of the predicate. The system sometimes uses a different print name for distin-guished numerical predicates.
negation node [Function]
This is a flag that is T if the predicate is negated. May also be NIL or UNKNOWN.
parguments node [Function]
In predicate nodes that occur in plans and world models, this is a list of varptrs representing the argu-ments to the predicate. In predicate nodes that occur in operator nodes and plot nodes, this is a list ofvardeses.
open-predicate node [Function]
This returns T if node is an open world predicate, NIL if it is closed world.
ltype node [Function]
Another slot used by the system for distinguished numerical predicates.
F.5 Slots on Operators
The functions for accessing the slots of operators were described in Section 13.1.
208
F.6 Functions for Plan Objects and Contexts
Plan objects and contexts are described in Sections 15.4 and 15.5. The following API functions can beused to find contexts, names, and plan objects from names and nodes.
Functions that return plan objects
find-plan-for-plan-name name [Function]
Nameis a plan name. Returns first plan object that has this name as its action-network name. (NOTE:this function is misnamed, it will be find-plan-for-action-network in future versions.)
find-plan-for-name name [Function]
Namecan be either a plan name or an action-network name. Returns first plan object that has this nameas a plan name or action-network name.
find-plan-for-planhead-context ph cpp-list [Function]
If a plan object is registered for the given planhead node and context, return the corresponding planobject.
find-plan-for-planhead ph [Function]
Returns first plan object that has the given planhead node as its last planhead. This function should notgenerally be used, as many plans may have the same planhead node. It is provided for error recoverywhen the context or name for some node is not known.
checkcontext name [Function]
This function checks if the given name is bound to a plan object. If so, the plan object is returned, elsewarnings are printed, and NIL (for a NIL input or a name that is bound to NIL) or the symbolNOisreturned.
Miscellaneous functions
name-context name [Function]
Prepends ”PLAN-” to name and returns the resulting symbol after interning it in*sipe-kb-package* .
209
F.7 Functions for Traversing Plans
The remainder of this appendix briefly describes some of the most important functions in SIPE–2 not
easily accessible through the top-level menus. Breaking or tracing these functions may be useful for
debugging. In certain cases, calling them may be useful. Many other functions not detailed here are also
helpful. In particular, functions in the file debug.lisp are written as debugging aids.
mapplan fn node plan-con &key skip process filter depth-arg [Function]
This function traverses from node applying the function FN to every node. If plan-con is nil, this is
done for all contexts (e.g., can be used on operator plots with nil context).
filter: if non-nil, then only apply FN to nodes for which (filter node) is non-nil.
depth-arg:if non-nil, then assume FN takes two arguments, the second being the depth of the node
inside of split and cond nodes.
skip: is a list of nodes types for which to skip application of FN. Skip can also be the atomcontrol
which translates to ’(split join cond endcond choice dchoice) as the value of skip.
process:is also a list of node types and is the converse of SKIP. If non-nil, only nodes with the given
types have FN applied.
advancesame node &optional plan flag [Function]
This function is used in most system plan traversals and returns the node following its first argument.
This function should not be called on a node with multiple successors. Unless the third argument is T,
advancesame keeps going past any choice or dchoice node in plan.
find-node-in-split node split plan [Function]
This function returns the successor of the split that contains node.
find-end node plan [Function]
This function returns the last node in the plan after node in plan. It skips over split-join pairs, so returns
nil if there is a split without a matching join.
findbegin node [Function]
This function returns the first node in the plan containing node.
find-common-split node node2 plan [Function]
This function returns the first split node having both node1 and node2 within its scope.
210
F.8 Functions for Critics
apply-critics node plan [Function]
This function applies all the critics to the plan beginning with node in plan. Also takes several keywords.
phantomizenet node plan &key cpp nobind split recheck numrecheck [Function]
Traverses a plan, beginning at node, checking goals to see if they can be changed to phantoms. Ifrecheck
set then also checks phantoms to see that they are still true. Ifnobindset, no constraints are posted while
phantomizing (i.e., phantomizing fails unless an exact match is found).
phantomize node plan cpp &key nobind recheck split copydown [Function]
Called by Phantomizenet on each node it attempts to phantomize.Split may be a list of split nodes
which represent nested splits which contain node in the same hierarchical level of the plan. This may
order nodes from these splits in order to phantomize node.
find-instantiation vps plan [Function]
Solves global constraint satisfaction problem to find a legal instantiation for each variable invps. Returns
a list. If failure, car of the list is nil and the cdr is an explanation. Otherwise, each element is a list whose
car is a vp invpsand whose second element is a varptr to instantiate it to. Varptrs invpswhich are
already instantiated are not on the list that is returned. If one vp has no possibilities, return dotted pair
of NIL and that vp. If two vps are forced to contradict each other, return list of nil, one of them and the
atom OTHERFORCED. Called by SIPE–2 as a critic ateach planning level, and at other times. Can be
called whenever desired, the tradeoff is spending more time checking constraints vs finding unsatisfiable
constraints more quickly.
add-resource-constraints node plan [Function]
Goes through a plan and posts constraints to avoid resource conflicts.
find-res-conflicts node plan [Function]
Traverses the plan from node until a split is found. It then goes to the lowest hierarchical level of
expansion inside split to look for resource conflicts.
fix-res-conflicts conflicts plan [Function]
Finds res-arg conflicts in conflicts and reorders them by putting the res branch first.
find-cbg-conflicts node plan [Function]
211
Finds clobber-brother-goal conflicts in a plan.
fix-cbg-conflicts conflicts plan [Function]
Employs algorithm to fix clobber-brother-goal conflicts. Puts preconditions before purposes.
fix-mbt-conflict node plan [Function]
Attempts to fix any parallel-postcondition problems by inserting new goals in the plan to reachieve the
postconditions.
F.9 Functions for Truth Criterion
The following functions are all useful for finding out why something is not true when you think it should
be:
matchcond cond node plan &key nobind current [Function]
This checks whether a list of predicates, cond, is true at node. If current is non-nil, then take the effects
of node into account. If nobind is non-nil, then no constraints are posted. The system also uses other
keywords not described here.
worldcollect pred-node plan node [Function]
This is called by Matchcond for each predicate in cond and has several keywords used internally by the
system. It implements the truth criterion, traversing the plan from node to the beginning to decide if
pred-node is true. When appropriate, it returns the answer-node (i.e., the node in the plan that made
pred-node true) consed onto front of whatever else it returns. Worldcollect returns T whenever pred-
node must necessarily be true, and nil when pred-node must necessarily be false. If other cases, it returns
a dotted pair where the car is an add-list and the cdr a delete list. This can be used to constrain variables
to make pred-node true. The add-list can be T (in which case constraints need only prevent an element
of the delete list from matching pred-node).
matchpred pred-node1 pred-node2 &optional same plan opr? [Function]
The basic function for determining if two predicates unify. Pred-node1 always comes from the effects of
a plan node and so does not have existential variables in it. Pred-node2 is an arbitrary predicate, it may
come from a plan effect or an operator condition and may have existentials and universals. If same is T,
find only an exact match (using function samevp); if NIL, find any match (using matchvps function); if
same is the atom SOME, note samevp match (if there is one) but try to match with matchvps if not, if
212
same is the atom SAMEUNI, find only an exact match but match differently when both predicates are
universals.
If no match return nil else return dotted pair: car is WIN or LOSE which indicates match with or
without negation agreement, cdr is T if match is all samevp. If opr? is t, then force use of samevp
when matching any nonvariable from pred-node2. This is done when pred-node2 is a precondition of
an operator, and prevents variables in the problem from being constrained by instances in an operator
precondition. (Necessary to prevent tests of operator applicability from garbaging the problem.)
matchvps vp1 vp2 plan [Function]
This is called by Worldcollect, matchpred and by many other routines to see if two varptrs can be unified
with each other. It checks the local constraints and part of the constraint network to determine this. It
is one of the most important and basic functions in the system. Several optional arguments are used
internally by the system.
F.10 Functions for Variables
samevp vp1 vp2 plan [Function]
Returns t if the two varptrs must be necessarily the same in this plan without addition of constraints.
doinstan vp1 vp2 plan cpp [Function]
Constrains vp1 to be the same as vp2 on . This posts aninstan constraint if either is instantiated, and a
same constraint otherwise. It also propagates the consequences of this and may fail (returns nil). This is
called by SIPE–2 to unify two variables, e.g., to make a precondition true so an operator can be applied.
getvps node plan [Function]
Collects all uninstantiated varptrs in the plan beginning with node.
possible-instantiations vp plan [Function]
Returns all objects that could be possible instantiations of vp, given its constraints in the given plan. For
non-numerial vps only – usecompute-s-r for a similar capability on numericals.
compute-s-r vp plan [Function]
Takes a numerical vp and computes its range of possible values. If only one value is consistent, the vp is
instantiated. This function returnsNIL if constraints are inconsistent,T if no constraint was posted (i.e.,
the range of possible values cannot be restricted), and the new range when a newsummary-range
constraint is posted. Additional optional arguments not listed here allow other options, such as not
posting constraints. Primarily, this computes the consequences ofrange and functn constraints,
where the latter may require their arguments to be instantiated before the computation can proceed
(when the function is declared in the variableno-range-functions ).
213
get-attribute node attr &optional plan [Function]
Returns the value for attributeattr on node (a variable node or a hierarchy node) in the plan. No
plan is required for hierarchy nodes. Only the first occurrence is returned, so not able to return, e.g., all
PRED or NOTPRED constraints — useget-attributes for that.
get-attributes node attr &optional plan [Function]
Attr should be a constraint or attribute name that has a list as its value (the global variable
vplistattrs specifies such constraints). Returns a list made by appending all values ofattr on
node in plan. Node should be a variable node or a hierarchy node. No plan is required for hierarchy
nodes.
add-constraint constr node &optional plan [Function]
This adds the constraint,constr , to a node and propagates it if appropriate (i.e., same, notsame
constraints). To add instantiations, the functiondoinstan should be used instead of this function.
The plan argument is used only on calls fromdoinstan so should not generally be given (it al-
lows all same constraints to be collected). This function does not generally check for compatibil-
ity or subsumption of constraints. Constr is a three-element list of(constraint-name value
cpp) , which requires knowledge of the syntax for constraint values. A suitable value forcpp is gen-
erally (plan-last-choice *current-plan*) . For example, thenot-same , res-ns , and
not-instan constraints all take lists of vartprs as their values. Thus a function used for procedural
attachment or instantiation could add anot-instan to an object named B as follows (whereVP is
bound to the current varptr):
(add-constraint (list ’not-instan
(list (cons ’B B))
(plan-last-choice *current-plan*))
(cdr VP))
214
F.11 Functions for Time Windows
There are two sources of temporal information for any plot node, the arguments of the node itself (e.g.,
latest-start.2) and the time window returned by Tachyon. Generally, SIPE–2 merges these two sources,
but they can be accessed individually.
The following functions return the specified temporal value for a plan node after merging both
sources of temporal information. Default intervals of 0 andposinf are returned if no information is
available.
earliest-start node plan [Function]
latest-start node plan [Function]
earliest-end node plan [Function]
latest-end node plan [Function]
shortest-duration node plan [Function]
longest-duration node plan [Function]
The following functions return the specified temporal value from the arguments only:
arg-earliest-start node plan &optional (default 0) [Function]
arg-latest-start node plan &optional (default ’posinf) [Function]
arg-earliest-end node plan &optional (default 0) [Function]
arg-latest-end node plan &optional (default ’posinf) [Function]
arg-shortest-duration node plan &optional (default 0) [Function]
arg-longest-duration node plan &optional (default ’posinf) [Function]
This function returns a structure holding a 6-tuple of numbers from Tachyon only:
get-time-constraints node plan [Function]
215
F.12 Index to SIPE-2 Source Code
This section indexes the source code to aid users in finding functions they may want to use or customize.
Note that the functions in the file debug.lisp are written as debugging aids.
SIPE-2 Definitions and BasicsFile Description---------------------------------------------------------------------------sysdcl-sun declares files for SIPE-2 system---------------------------------------------------------------------------globals-customize Definition of global variables that user may
set to customize behavior of the planner---------------------------------------------------------------------------globals Definition of other global variables---------------------------------------------------------------------------node-classes Definitions & creation functions for Sipe nodes---------------------------------------------------------------------------macros Functions for modifying the fields of Sipe nodes---------------------------------------------------------------------------compatibility-macros Defines macros that are different over Lisps---------------------------------------------------------------------------parallel-links Structures and methods to deal with parallel links---------------------------------------------------------------------------
Interaction---------------------------------------------------------------------------sipetop-menu-interface Menus for top-level commands---------------------------------------------------------------------------plan-interactive Interactive planning & search functions---------------------------------------------------------------------------display Functions to print SIPE structuresenglish---------------------------------------------------------------------------display-interact Menus to control displaying of structures---------------------------------------------------------------------------debug Useful functions for debugging (not used in SIPE-2)---------------------------------------------------------------------------
Top-level---------------------------------------------------------------------------plan-toplevel Top Level planning functions---------------------------------------------------------------------------plan-search Functions for the search algorithm---------------------------------------------------------------------------plan-control Functions for bookkeeping, copying nodes---------------------------------------------------------------------------plan-expansion Functions for plan node expansion---------------------------------------------------------------------------plan-backtracking Functions for backtracking---------------------------------------------------------------------------deduce Functions to apply deductive operators to a plan---------------------------------------------------------------------------traverse Functions that traverse a plan doing useful things---------------------------------------------------------------------------
216
CriticsFile Description---------------------------------------------------------------------------plan-critics Functions for applying critics to a plan---------------------------------------------------------------------------variable-allocations Functions to satisfy constraints and bind variables---------------------------------------------------------------------------resource-critic Functions to detect and solve resource conflicts---------------------------------------------------------------------------cbg-critic Functions to detect and solve protection violations---------------------------------------------------------------------------phantomize-plink Functions to phantomize nodes/plans---------------------------------------------------------------------------temporal Functions to process temporal constraints---------------------------------------------------------------------------tachyon Functions to communicate with Tachyon system---------------------------------------------------------------------------
Execution Monitor and Replanner---------------------------------------------------------------------------plan-execution Functions for top-level execution monitoring---------------------------------------------------------------------------exutl Functions used by execution monitor---------------------------------------------------------------------------replan Functions for replanner---------------------------------------------------------------------------
GUI---------------------------------------------------------------------------draw-plans-grasper Define methods to draw plans in GUI---------------------------------------------------------------------------draw-basics-grasper Define methods for drawing each node in GUI---------------------------------------------------------------------------gui-draw-plan Functions for drawing plans---------------------------------------------------------------------------grasper-symbols Imports symbols from grasper package---------------------------------------------------------------------------grasper-hacks Defines useful functions that are not in Grasper---------------------------------------------------------------------------colors Functions for colors---------------------------------------------------------------------------completion Functions for menus, completionctv-choice---------------------------------------------------------------------------gui-menus These files define the grasper-based GUI,gui-functions including command menusgui-modes---------------------------------------------------------------------------sipe-layout Functions for laying out nodes on the screen.---------------------------------------------------------------------------sipe-act Defines functions to translate SIPE to ACT.act-sipe Defines functions to translate ACT to SIPE.---------------------------------------------------------------------------
217
Truth Criterion and ConstraintsFile Description---------------------------------------------------------------------------world Functions for applying truth criterion---------------------------------------------------------------------------tc Functions that define the truth criterion---------------------------------------------------------------------------constraint Functions dealing with constraints---------------------------------------------------------------------------match Functions for unifying two variables---------------------------------------------------------------------------represent Functions for variables, constraints, hierarchy,GFP---------------------------------------------------------------------------
Numerical Features---------------------------------------------------------------------------numerical Functions for SIPE-2 numerical capabilities---------------------------------------------------------------------------numerical-util Functions for low-level number manipulations---------------------------------------------------------------------------world-numerical Functions for numerical constraints in TC---------------------------------------------------------------------------
Internals---------------------------------------------------------------------------node-accessors Functions to manipulate nodes, modify slot values---------------------------------------------------------------------------reset Functions to reset SIPE-2 and name structures---------------------------------------------------------------------------setup Defines needed sort-hierarchy classes---------------------------------------------------------------------------parallel-group Functions to make alternative orderings of a plan---------------------------------------------------------------------------adlsup Functions for bookkeeping of the plan structure---------------------------------------------------------------------------copy-plan Functions for copying an entire Sipe plan---------------------------------------------------------------------------bind Functions for binding operators to plan variables---------------------------------------------------------------------------adl-num Functions needed to interpret plots of operators---------------------------------------------------------------------------desc Functions dealing with DESC and ANCES slots---------------------------------------------------------------------------parser-utils Defines functions used by parser---------------------------------------------------------------------------variable-accessors Defines functions for vardeses and varptrs---------------------------------------------------------------------------parser Defines all top-level functions of the parser---------------------------------------------------------------------------
218
Appendix G
Implementing Parallel Links
Using parallel links to allow all possible orderings of unordered actions requires a useful, efficient,
implementation to maintain an efficient truth criterion while taking into account arbitrary ordering links
that may exist. This appendix documents some of the details of the SIPE–2 implementation for the
programmer.
SIPE–2 permitsparallel links which are defined as successor and predecessor links that can be
placed between any two actions in a plan that are unordered with respect to each other. Such links will
be referred to as p-predecessor and p-successor links to distinguish them from successor and predeces-
sor links that have always been part of the plan. This is done because the plan-traversal algorithms must
follow these links differently. These algorithms follow links from node to node and recurse upon them-
selves when split-join nodes are encountered. However, parallel links may link nodes inside a split-join
to nodes outside that split-join, thus invalidating the recursive algorithms used in SIPE.
The representation of parallel links is complicated by the use of hierarchical planning levels and
SIPE–2’s ability to represent alternative plans in different contexts. There may be a number of parallel
links at any one node, e.g., there may be multiple p-predecessors. However, some links may not apply
to the current plan and context but rather apply to an alternative expansion of the plan. There are also
complications in copying these links down to more detailed expansions of the plan, since some nodes
may be expanded to the more detailed level while other nodes may not be. Thus the TC and other
algorithms have to be able to calculate the lowest-level expansion of the node to which they are linked.
The highest-level instance of any plink is stored on theparallel-predandparallel-succslots of a node.
For efficiency reasons, the system stores links at lower levels in the slotsparallel-pred-hereandparallel-
succ-herewhen they can be calculated, rather than recomputing links by always following the links from
the highest-level.
The changes to the critics and solvers were fairly straightforward. The solvers now add ordering
constraints by adding p-successor and p-predecessor links, and there is an algorithm to determine if two
219
nodes are still unordered with respect toeach other when parallel links are present. This algorithm is
implemented by the methodplink-ok? and the functionplink-ok?-fun . Plink-ok? becomes
a basic operation in many parts of the planner, but is a nontrivial algorithm which must check if either
node is ordered before the other. To see ifnode1 is ordered beforenode2, the system must find the
common split-join that includes both nodes, then attempt to follow p-predecessor and predecessor links
from one set of nodes (the nodes fromnode1 to the common join) into a second set of nodes (the nodes
from node2 to the common split).
Parallel links make the TC much more complex, although heuristic adequacy is retained by incor-
porating the same heuristic of looking for one possible ordering that makes a predicate true. This can
still be done efficiently in SIPE–2. The TC traverses the nodes in a plan from the end of the plan to the
beginning, taking into account the effects of each node. The algorithm naturally recurses on itself when
split-join nodes are encountered. The TC must wait to process the effects of nodes with p-successor
links until nodes that necessarily come after these nodes in other branches of some enclosing split-join
are processed. Since split-joins may be nested arbitrarily deeply, this may involve popping up through
several levels of recursion for additional processing and then returning to the computation that was sus-
pended. Furthermore, the suspended computation cannot simply wait for its p-successor to be processed
because the TC may determine an answer on that branch before it ever processes the p-successor node.
Another complication in the TC occurs when it is trying to determine the truth of a predicate at
a node (called the current node) inside a split-join. The TC marks all nodes that must precede the
current node by virtue of p-predecessor links, then starts traversing the plan from the outermost join that
includes the current node. This is the same TC algorithm except that it ignores unmarked nodes.
220
Appendix H
CLIM Peculiarities and Bugs
In the CLIM implementation, a new GUI can be created by calling the function(run-sipe) from the
top level of Lisp. To get to the top level of Lisp, click onApplicationand then onExit or interrupt the
Lisp process with two control-Cs and abort. To use SIPE–2 without the GUI, the CLIM root window
must first be initialized by calling(run-sipe) and then exiting.
During interactive planning, some commands, e.g.,Suspend to Display, create an additional GUI.
Planning is continued when the new interrupting GUI is exited (by clicking onExit in the Applications
menu), thus giving control back to the original SIPE–2 GUI.
The CLIM implementation does not support the following capabilities:
� Middle clicks on commands. On Symbolics, the left click often performs some command onthe currently displayed SIPE–2 structure while the middle click performs that command on anystructure selected by the user. In the CLIM implementation, the user must first draw the selectedstructure and then perform the command on it.
� Printing of mouse-sensitive text. Underlying data structures that are represented by printed textcannot be accessed by clicking on the text.
� The common-lispload function cannot be used to load SIPE–2 input files because Lucid’s lispswitches the input stream from the file to the terminal when expressions read from the inputstream are evaluated. The SIPE–2 function, lucid-load , loads files without changing theinput stream. The functioneval-load does aload when not in Lucid, alucid-load inLucid, and is the recommended function for loading SIPE–2 input files.
H.1 Stuck States
This section is reproduced from Chapter 10. The termstuck staterefers to the situation when the GUI
apparently does not respond to input. Stuck states can arise for different reasons because of known
221
CLIM bugs. Several remedies are given below. CLIM does not update the GUI window until SIPE–2
returns to the CLIM command loop. Thus the GUI will be unresponsive while SIPE–2 is computing.
For example, suppose the user invokes automatic problem solving (which may take several minutes) and
then either closes the GUI window or exposes another window on top of it. Upon reopening, the GUI
window will be completely blank with all displayed information gone and no indication that the GUI is
active. Simply wait, and when SIPE–2 returns to the CLIM command loop the screen will be refreshed
and displayed information will reappear. If planning is taking longer than expected, then the remedies
below should be tried. If none of them work, Unix commands can be used from another window to
determine whether the SIPE–2 Lisp process is still running. The remedies are these:
1. Try clicking right on the background. A common stuck state occurs when the GUI is in a loopreading mouse clicks. Clicking right on the background exits such loops, and also recovers froma stuck state described in 2, below.
2. Sometimes when the GUI should be in the command loop (e.g., after returning to the commandlevel from an error), it does not respond to mouse clicks. Let’s call this Stuck-state-1. Typing aReturn (or other input) restores CLIM. Unfortunately, if CLIM is not in Stuck-state-1, typing anextraneous Return puts CLIM in Stuck-state-2.
3. CLIM enters Stuck-state-2 when an extra Return has been typed. In this state, the GUI Lisplistener generally displays the message:The input ‘‘’’ is not a complete Lisp Expression. Please edit your
input.
Doing a right mouse-click anywhere in the GUI restores CLIM from Stuck-state-2. Alternatively,selecting any mouse-activated command in the command pane simultaneously initiates thecommand and exits Stuck-state-2. A right mouse-click never gets CLIM stuck, so it is always agood first attempt at recovery.
4. Another cause of stuck states is errors, which can be hard to recognize in CLIM. If an error occurs,nothing appears in the GUI. Any error message will be in the window from which the Lisp processwas first run. So if the GUI seems to have stopped, check the Lisp window for an error. Errorsgenerally include a continuation option to return to the SIPE–2 command level, and this shouldgenerally be selected.1
5. If the GUI becomes hopelessly wedged, it is best to kill it and create a new one.2 Killing is doneby interrupting the Lisp process (type controls-C twice to the Lisp window), aborting to the toplevel, and calling the function(run-sipe) again. If even that fails, try meta-x panic.
1If any SIPE–2functions are called from the break in the Lisp window, their output will often still go to the CLIM windowand not to the Lisp window where the function is called. To get the output in the Lisp window,*sipe-output* must bebound to*debug-io* .
2On the Symbolics, this is done by killing the correctGrasper Graphicsframe in the select-P window, then typing select-Gagain.
222
H.2 Parameter Menus
There is an annoying misfeature of CLIM that can surface in paramter menus (for choosing values
for different features). If CLIM will not let you exit from such a menu, it generally means that it is
still accepting input on one of the menu items. Move the cursor over the menu, and one of the items
should have a cursor appear near it, indicating that item is stillaccepting input. If the cursor is already
highlighted, type Return to exit the accepting input for that item, and then the entire menu can be exited.
If the cursor is not highlighted, then first click left in the menu entry to activate it, and then type Return.
H.3 Completion
The following known CLIM bugs affect completion:
1. After completing to a legal name, then typing to extend it to a new name, CLIM reverts back to
the completed name. To extend the name, simply backspace over its last character, type it again,
and then continue typing.
2. After selecting a completion from a menu, it is sometimes necessary to press the return key to see
it.
3. When no completions are found, CLIM erases the input so far. It is necessary to reenter any
substring that had been typed.
H.4 Miscellaneous Bugs
Often, a right click on an item such as a command or an item in a menu causes CLIM to bring up a
menu of choices that it has generated. These choices often sound good, but they do not work. Selecting
one of them causes an error in the Lisp window. Simply click left or right on the background to make
these CLIM menus disappear.
In SIPE–2, the default on black and white monitors is to draw precondition and phantom nodes
with gray borders. In the CLIM implementation, this appears to slow down drawing by an order of
magnitude. Drawing is still fast for plans with dozens of nodes, but for plans with hundreds of nodes an
alternative drawing style is recommended: load the filesipe:sipe;clim-draw-methods .
Because of a bug in CLIM, dragging of nodes using theMovecommand in the NODE menu does
not work properly. If the user holds the button down during the move operation, a ‘ghost’ copy of
the node may appear. The ghosts can be eliminated by clicking onRedrawin the DRAWING menu.
Moving nodes by clicking on them works properly provided you simply click on the node, then click on
the destination for the node without keeping the button depressed throughout the operation.
223
Index
Symbols*abbreviations* variable, 56, 57
*act-interactive* variable, 200
*action-documentation-strings* variable, 57–
59
*all-plans* variable, 144
*attribute-names* variable, 57
*browser-image* variable, 66, 68
*browser-options* variable, 66
*cbg-frequency* variable, 142
*cbg-opr-list* variable, 45
*check-precond-conflicts*, 142
*check-precond-conflicts* variable, 102, 120,
142
*check-preconds-in-interp* variable, 102, 120,
142
*copy-comment-down* variable, 108
*copy-comment-from-opr* variable, 108
*copy-comment-to-expansion-purpose* vari-
able, 108
*copy-properties-down* variable, 108
*copy-properties-from-opr* variable, 108
*copy-properties-to-expansion-purpose* vari-
able, 108
*current-node* variable, 160
*current-plan* variable, 43, 145, 201, 203
*current-plans* variable, 27, 144, 200, 201, 203
*default-depth-limit* variable, 30, 200, 201
*default-domain* variable, 71
*describe-opr-in-popup* variable, 42, 66
*documentation-strings* variable, 57–59
*domain-choices* variable, 71
*domain-critic* variable, 140
*domain-critic-frequency* variable, 140
*domain-name* variable, 71, 87, 89, 104
*domain-problem-file* variable, 12, 104, 109
*domains* variable, 71
*duration-as-uncertainty* variable, 170, 172
*expandable-plans* variable, 38
*external-executor* variable, 77, 78
*fail-on-resource-conflict* variable, 139
*flash-link-defaults* variable, 62
*flash-plink-function* variable, 138
*generate-earliest* variable, 173
*generate-interval-constraints* variable, 167,
173
*gkb-kb* variable, 89
*goal-documentation-strings* variable, 57–59
*independent-goals* variable, 137
*init-problem-function* variable, 135
*instantiation-function* variable, 33
*interactive-res-conflict* variable, 41, 138
*last-plan* variable, 144
*leave-opr-args* variable, 123
*max-popup-height* variable, 67
*max-popup-width* variable, 67
*menu-for-unexpected* variable, 78
*node-color-menu* variable, 60
*pane-color-menu* variable, 60
*parallel-phantomize-by-addition* variable,
140, 166
*popup-text-size* variable, 66
224
*prevent-same-solution* variable, 77, 78
*print-to-popup* variable, 66, 67
*public-domain-strings* variable, 71
*public-domains* variable, 71
*res-opr-list* variable, 45
*res-res-conflicts-only* variable, 143
*resource-frequency* variable, 142
*retry-level-processes* variable, 79, 81
*retry-processes* variable, 79, 81
*save-opr-arg-bindings* variable, 108
*select-replan-goal* variable, 77, 78
*select-with-completion* variable, 96
*set-node-shapes-function* variable, 61
*sipe-dictionary* variable, 95
*sipe-output* variable, 99
*special-node-shapes* variable, 61
*tachyon-3-display-edges* variable, 169
*tachyon-format* variable, 169
*tachyon-output-path* variable, 168
*temporal-frequency* variable, 143
*time-critics* variable, 102
*time-deduce* variable, 102
*time-each-level* variable, 102
*time-limit* variable, 30, 200, 201
*time-pc* variable, 102
*unexpected-predicates* variable, 76, 80
*use-abbreviations* variable, 57
*use-act-dictionaries* variable, 95, 97
*use-gkb-sort-hierarchy* variable, 205
*use-tachyon* variable, 167, 168
*user-chooses-goal* variable, 41
-> ACT all command, 13, 86, 94
-> ACT command, 13, 86
-> PRS command, 14, 86
-> SIPE command, 84
AAbstract command, 13, 26, 101
ACT command, 12, 84
ACT Options command, 14, 86
Act-Editor, 8, 12–14, 19, 83, 84, 86, 91–96,
105, 107, 118, 127
act-sipe-mode function, 93
action function, 127, 131, 207
Acts, 13, 84–86, 91, 92, 94, 196
Add Facts command, 13, 43, 74
Add Goal command, 13, 43
add-constraint function, 141, 214
add-plinks-for-time variable, 137
add-protect-untils variable, 139
add-resource-constraints function, 211
add-sipe-dictionary function, 94, 95
additions, 116, 191
advancesame function, 210
advice, 2, 3, 11, 60
Advisable Planner, 3, 31, 33, 34
Align command, 15
Align-mode command, 15
ances function, 206
answer-names variable, 43
Application command, 9
apply-critics function, 211
arg-earliest-end function, 215
arg-earliest-start function, 215
arg-latest-end function, 215
arg-latest-start function, 215
arg-longest-duration function, 215
arg-shortest-duration function, 215
args-flag variable, 56
Argument command, 16, 22
arguments function, 120, 123, 127, 128, 131,
132, 206
auto-execute variable, 77–79
auto-interactive-search variable, 79
auto-replan variable, 43, 77–79, 203
225
automated-planning-display variable, 138, 202
automated-replanning-display variable, 138,
202
Automatic command, 11, 13, 21, 23, 26, 30, 31
automatic-allocation variable, 41, 138
BBackup command, 15
big-lnlength variable, 66
Birds Eye command, 12, 54
black-and-white function, 60
both-operator, 118, 153
branch, 128, 193
Browse command, 14, 15, 52, 53
browsing space, 53
Ccausal-rule, 118
causal-rules, 151
causal-rules variable, 65
check-pc-before-choosing variable, 41
checkcontext function, 209
choice node, 145
choice pane, 10, 41
choice-nodes function, 125
choiceprocess node, 45, 59, 127, 131, 139
choices variable, 38
class node, 111, 113, 194
Clear Plans command, 12, 104
clg:*global-dictionaries* variable, 95
clg::act-sipe-mode function, 93
clg::full-menu-mode function, 93
closed-predicates, 115, 117, 191
closed-world assumption, 115, 152
collect-footprint function, 101
Colors command, 12, 59, 60
comment function, 107, 113, 121, 207
Completion command, 11, 15, 96, 97
compute-s-r function, 213
cond node, 127, 196
condition function, 120, 121
condpattern node, 127, 128, 193, 196
consume, 140, 158, 162–164
contexts, 5, 12, 27, 46, 68, 69, 101, 102, 125,
135, 144–146, 149, 199, 219
Continue command, 13, 24, 26, 31, 33, 35, 201
Continue-1 command, 13, 21, 26, 31, 33, 35,
36, 201
convert function, 87, 114, 115
copy, 128, 193
count-nodes function, 100
CPP, 145, 146, 204, 206, 213, 214
Dd function, 65, 204
dcontext variable, 145
dcontext* variable, 145
debug-domain variable, 105
debug-search-detailed variable, 29
debug-search-detailed-nodes variable, 29
debug3 variable, 29
declare-proc-att function, 140
declare-sipe-kb function, 89
deduce function, 207
default-colors function, 60
default-special-node-shapes variable, 61
define.domain function, 109, 117, 128, 190
define.problem function, 109, 128, 190
delay, 44, 82, 127, 130, 131
delay-execute, 44, 82, 127
delayp function, 130
Delete Goal command, 13, 43
desc function, 206
Destroy command, 13, 14
Destroy-multiple command, 14
dictionary, 12, 13, 84, 86, 91–96
226
Dictionary command, 12, 94, 95
dinode function, 67
disable-temporal-reasoning function, 167
display-in-browser function, 67, 68
displaypkg function, 65
dispnode function, 67
dispnode-popup function, 67
dnode function, 67, 68
doinstan function, 213, 214
Domain command, 11
domain files, 20
Draw command, 14, 47, 49
Draw Objects command, 52
Draw Operator command, 51
Draw Operator-Graph command, 51, 52
Draw Plan command, 23, 49
Draw Plan Decomposition command, 23, 50, 51
Draw Problem command, 49
Draw World command, 52, 57
Drawing command, 11, 14, 47, 50, 57
duration, 127
duration-as-uncertainty, 170
Eearliest-end function, 215
earliest-start function, 215
effects function, 121, 127, 130, 207
Efficiency command, 11, 30, 44, 135, 141, 142
emacs-window, 64
enable-temporal-reasoning function, 167
endcond node, 127, 128, 196
establishers function, 100
eval-load function, 105, 203
Execute command, 11, 13, 79
Execute-any command, 13
execute.primitive function, 80
Execution command, 11, 76
expand-node function, 39, 101, 204
expand-x-layout variable, 50
expand-y-layout variable, 50
expandable plan, 36
expr, 125
external-condition function, 127, 130, 131, 150
Ffast-interactive-search variable, 30, 41, 79, 202
Find command, 12
find-applicable-operators function, 203
find-cbg-conflicts function, 211
find-common-split function, 210
Find-Edge command, 15
find-end function, 210
find-instantiation function, 211
Find-Node command, 15
find-node-in-split function, 210
find-plan-for-name function, 144, 209
find-plan-for-plan-name function, 32, 144, 209
find-plan-for-planhead function, 209
find-plan-for-planhead-context function, 209
find-res-conflicts function, 211
findbegin function, 210
fix-cbg-conflicts function, 212
fix-mbt-conflict function, 212
fix-res-conflicts function, 211
flash-node-on-expansion variable, 138
full-menu-mode function, 93
function constraint, 159, 160, 168, 213
GGenerate, 133
generate-goals, 127, 131–133
generate-plan function, 32, 200
get-attr-vals function, 205
get-attribute function, 214
get-attributes function, 214
get-hier-node function, 205
227
get-nodes function, 100
get-time-constraints function, 215
getvps function, 213
gkb-ed::http-kb-server function, 88
GKB-Editor, 8, 12, 14, 83, 86–89, 94, 105, 106,
113
goal node, 45, 48, 59, 79, 118, 123, 127, 131
goals function, 106, 123, 127, 131, 132, 206
graph (Grasper), 14, 19
graph create, 14, 20
graph destroy, 14
graph input, 14
graph output, 14
graph select, 14
HHardcopy command, 15
hierarchy-node-p-api function, 204
http:disable-http-service function, 88
II-Search command, 11, 21, 23, 30, 36–38, 40
id function, 67, 120, 129, 205, 208
id-api function, 204
id-flag variable, 56
indef, 125
inhibit-plan-printing variable, 77
init-operator, 118, 153
init-operators, 151, 153
init-operators variable, 66
init.deduce function, 116, 153
initial-additions, 117
initialize-problem function, 32, 200–202
Input command, 5, 11–13, 20, 23, 105, 203
instan constraint, 68, 140
instance, 125
instance node, 113
instances function, 113
instances-api function, 205
instantiate function, 103, 120, 123, 138, 154
interactflg variable, 41, 138
Interactive command, 11, 13, 24, 26, 34
Interactive-1 command, 13, 21, 26, 35, 36
Jjoin node, 48, 127, 196
Llastplanhead variable, 43, 65, 201, 203
latest-end function, 215
latest-start function, 215
Layout command, 9, 12, 24, 41
level, 77, 79, 81, 82, 140, 156, 158, 162–164,
166
lfile function, 105, 203
link-classes function, 114
List command, 12, 20
List Files Input command, 12
List Nodes command, 12, 101, 145
load-and-update function, 105, 203
load-new-file function, 105, 203
longest-duration function, 215
ltype function, 208
MMagnify command, 14, 55, 56
make-problem function, 129, 202
mapplan function, 210
matchcond function, 101, 212
matchpred function, 212
matchvps function, 213
mate function, 206
merge-final-time-sources variable, 167, 169
Modify command, 12, 43, 83, 87, 88, 113
mother.nature node, 43
Move command, 15
Move-group command, 15
228
Movie Mode command, 21
Movie-Mode command, 13, 26, 29
Multiagent Planning Architecture, 3, 83
multiple-answers variable, 30, 200, 201
Nname-context function, 209
name-flag variable, 56, 57
negation function, 208
New View command, 14, 22, 49–51, 56, 57
new-data-each-level variable, 136
no-range-functions, 103, 117, 154
no-range-functions variable, 160
Node Colors command, 11, 47, 59, 60, 81
node shapes, 47, 56, 57, 60, 61
Node Shapes command, 11, 47, 56, 60, 81
Node Sizes command, 11, 47, 55, 56
not-same constraint, 139, 140
notpred constraint, 140
num-or-vp function, 161
number-of-answers variable, 30, 200, 201
Numerical command, 11
numerical-enabled? variable, 136
numerical-template variable, 157
Oobject node, 111, 113, 194
Objects command, 12, 14, 22
old-interactive-choices variable, 38
old-plan-levels variable, 38
op-variable-names? variable, 110
open-predicate function, 208
open-predicates, 115, 117, 191
operator, 118, 193
operators variable, 65
original-context variable, 146
original-cpp variable, 146
Output command, 13, 14, 19
output-to-emacs function, 64, 100
output-to-GUI function, 100
PParallel command, 16
parallel-loop, 131
parallel-pred function, 150, 207
parallel-pred-here function, 150, 207
parallel-succ function, 150, 207
parallel-succ-here function, 150, 207
parent function, 113
parent-api function, 205
parent-class function, 113
parent?-api function, 205
parguments function, 208
pattern function, 127, 131
perfectworld variable, 79
phantom node, 48, 59
phantomize function, 211
phantomize-by-constraints-with-ordering vari-
able, 139
phantomize-by-constraints-without-ordering
variable, 139
phantomize-choiceprocess variable, 139
phantomizenet function, 211
plan object, 4, 32, 37, 46, 101, 102, 135, 143–
146, 199, 201, 202, 209
Planning command, 11, 27, 30, 40, 135, 166
plink-enabled? variable, 137
plot function, 121
pname function, 208
possible-instantiations function, 101, 213
precondition function, 120
precondition node, 48, 59
pred constraint, 68, 140, 158
pred function, 206
Predecessors command, 16, 22
Predicate command, 16
229
predicates, 116, 191
predicates-not-planned variable, 109
predname function, 208
primitive actions, 4, 48, 59, 80, 82, 84, 86, 109
primitive goals, 109
Print command, 12, 13, 15, 20, 63, 65
Print Node command, 64, 67
Print Object command, 52, 64
Print options command, 13
Print Plan command, 64
print-action-for-opr function, 203
Print-Ancestors command, 15, 23
print-footprint function, 101
Printing command, 11, 13, 15, 63
problem recognizer, 43, 75, 79, 203
problems variable, 65
procedural attachment, 140, 141, 214
process node, 45, 48, 59, 77, 79, 81, 109, 118,
123, 127, 131, 139
produce, 140, 158, 162–164
Profile command, 92
properties function, 107, 108, 113, 121, 125,
207
properties-api function, 204
protect-until, 127, 131, 139
purpose function, 120, 121, 123, 130, 207
Rrange constraint, 213
recheck-phan-deduce variable, 143
rededuce-oninstan variable, 137
Redraw command, 14, 15
Regroup command, 13, 26, 149
remove-redundant-actions-frequency variable,
143
Rename command, 13, 14
Reparse command, 14, 15, 50
replanner, 5, 43, 47, 59, 60, 74–77, 80, 81, 108,
137, 166, 203
Rescale command, 15, 55, 56, 62
Reset command, 11, 12, 23, 89, 95
Reshape command, 15
Reshape-group command, 15
Resource command, 16
resources function, 120, 123, 127, 131, 206
Revert command, 15
run-sipe function, 24, 61, 99
Ss function, 24
same constraint, 140, 214
samevp function, 213
Save command, 89
save-colors function, 60
save-hierarchy function, 115
Search Space command, 11, 23, 30, 40
Select command, 14, 19, 22
set-user-default-node-shapes variable, 61
set-user-node-shapes-from-defaults variable, 61
shortest-duration function, 215
sipe function, 24, 204
sipe-classes variable, 113
sipe-input-keyword variable, 106, 190
sipe-ws function, 71
sizes variable, 55
sjcontext function, 146, 206
skip-tachyon-time-windows variable, 168
sleep-time-for-movie-mode variable, 30
smallest-unit-first variable, 157
Solve command, 26
solve function, 30, 32, 33, 200–202
solve-act function, 32, 200
Solve-problem function, 32
solve-problem function, 200, 201
230
sort hierarchy, 4, 8, 12, 14, 52, 64, 67, 83, 86–
89, 91, 94–96, 101, 104, 105, 110–
114, 161, 167, 204
sort hierarchy API, 112, 204
sort-hierarchy variable, 52, 113, 194
space (Grasper), 19
split node, 48, 127, 196
start-time, 127
start-ws function, 71
start-www-server function, 71
state-rule, 118, 153
state-rules, 151
state-rules variable, 65
static-predicates, 117, 191
stop-time, 127
stop-ws function, 71
stop-www-server function, 71
stuck state, 98, 221
subclass-api function, 205
subclasses function, 113
succ function, 205
Successors command, 16
summary-range constraint, 213
Suspend to Display, 38
Ttime-constraints function, 121, 207
time-constraints-flag variable, 56
time-tuple, 167, 168
Trace command, 11, 27, 28, 30, 40
trigger function, 120, 121
truth criterion, 5, 6, 148, 149, 212
type function, 120, 125, 205, 208
type-api function, 205
Uunexecute function, 80
unknown, 74, 115
unlink-classes function, 113
update-tr-constraints function, 169
Vvardes, 125, 127, 199, 208
varptr, 125, 127, 141, 199, 208, 211, 213
verbatim-variable-names? variable, 110
Verifier, 91–94, 97
Verify command, 84, 86, 94
vp-print-id variable, 56, 66
WWeb Server, 70–72, 86, 88
what-if function, 43, 203
With, 124
World command, 22
worldcollect function, 162, 212
worlds variable, 129, 202
231
