Working Document

Transcription

Working Document

Working Document:
Revisions as of February 29, 2000
USING THE SIPE-2
PLANNING SYSTEM
A Manual for SIPE-2, Version 6.1
by
David E. Wilkins
Senior Computer Scientist
Artificial Intelligence Center
SRI International
333 Ravenswood Ave.
Menlo Park, California 94025
c David E. Wilkins
Copyright c SRI International
Software Unpublished Copyright All Rights Reserved
Act-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 Laboratory Rome supported later revisions of this manual under Contracts F30602-90-C-0086, F30602-93C-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 book Practical Planning: Extending the Classical AI Planning Paradigm, D. E. Wilkins, Morgan
Kaufmann Publishing, 1988, and in the sections of this document denoted as advanced 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.
S IPE –2’s home page, which contains pictures, descriptions of applications, and installation instructions, can be found at http://www.ai.sri.com/˜sipe
ii
Contents
1 Overview
1
1.1
System Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
S IPE –2 as an Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3
Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4
Planning Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2 Starting and Controlling SIPE-2
2.1
8
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
Controlling the Solution Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.5.1
Instantiating Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.5.2
The Advisable Planner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.5
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
8.1
8.2
8.3
83
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
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
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
F.2
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
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 S IPE –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.
S IPE –2’s home page, which contains several pictures, descriptions of applications, and installation
instructions, can be found at http://www.ai.sri.com/˜sipe
This document contains sufficient information about S IPE –2 for a user to use a S IPE –2 application
already developed for a particular problem domain. However, a S IPE –2 programmer, i.e., someone
attempting to model a new domain in S IPE –2, should be familiar with the representational ideas underlying 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 paper Can AI planners
solve practical problems? [9]. Certain sections of this document labeled as advanced concepts can 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 S IPE –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 S IPE –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.
1 It
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, S IPE –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, S IPE –2 is capable of
generating a novel sequence of actions that responds precisely to the situation at hand.
S IPE –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. S IPE –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, S IPE –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.
S IPE –2 provides a powerful formalism for representing domains and automatically generating plans
in them. However, many types of domains cannot be represented adequately in S IPE –2, including domains 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 contribute 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. S IPE –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. S IPE –2 can then identify 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, S IPE –2 provides a rich
advice-taking facility. With this facility, users can direct the planning process in a powerful and general
2 The 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 of S IPE –2 .
2
manner through the provision of high-level guidance 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. As such, advice is an adjunct to the domain knowledge that
underlies a given planning application. Details of the advice-processing capabilities within S IPE –2 can
be found in a companion document [5].
1.2 SIPE –2 as an Agent
This manual describes the stand-alone use of S IPE –2 as a planning system. S IPE –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 cooperative planning and problem solving.
MPA is a separate software system that can be obtained from SRI. MPA includes two S IPE –2-based
agents that responds to various messages that can be sent to S IPE –2 to invoke its planning capabilities. MPA provides an agent wrapper in L ISP that supports asynchronous interagent communication,
including functions for making, sending and replying to messages that log and trace the message exchange. 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 L ISP 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 L ISP 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 at http://www.ai.sri.com/˜wilkins/mpa
1.3 Basic Concepts
The inputs and outputs of S IPE –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 of
the World
Actions One
Might Take Problems
Planner
Action
Structure
Beliefs,
resources,
constraints
Operators
Actions
Goals
Execution Monitor
and Replanner
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 of primitive actions to be carried out by whatever
agents are accepting instructions from the planner.
S IPE –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 a sort 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. An operator 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 execution. 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 and context. 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 the Input command under the Domain
menu, and loading the initial default file (sipe:input;blocks.sipe). Appendix F describes each 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.) The truth 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.
3 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.
5
SIPE-2 Top Level
automatic or interactive
Resource
Reasoning
&Allocations
Plan Critics &
Solvers
Execution
Monitoring &
Replanning
Replanning
Actions
Interpreter
Deductive
Causal Theory
Truth Criterion and Unification
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.
S IPE –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 of each 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 the plan rationale that 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 Level
automatic , interactive, or controller agent
Select a goal
Select an
operator
Apply operator to
goal
Deduce
consequences
PLAN EXPANSION PHASE:
continues until controller
decides to critique plan
Plan Critics &
Solvers
Modify plan to
avoid conflicts
PLAN CRITIQUE PHASE:
continues until all conflicts
corrected or deferred by
controller
FINAL PLAN :
-all goals expanded
-all conflicts corrected
Figure 1.3: SIPE-2 Search Control
levels of abstraction.
7
Resource
allocation and
scheduling
Chapter 2
Starting and Controlling SIPE-2
First, log on to the computer, enter the appropriate window system, start running a C OMMON L ISP 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 S IPE –2 without running it, call (sri:load-system
:sipe). Loading S IPE –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 is not loaded when S IPE –2 is loaded. If the user desires to use the GKB-Editor, the
system can be loaded by evaluating (load-gkb) after loading S IPE –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, S IPE –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 S IPE –2.
This chapter describes the graphical user interface (GUI) of S IPE –2, and then describes an example
planning session.
1 Grasper
will be used throughout this manual to refer to the most recent Grasper systems available. Currently, these are
Grasper 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 S IPE –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, which accepts 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).
The Layout command 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 S IPE –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
S IPE –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, S IPE –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 on Domain to display the Domain menu,
clicking on Reset (if another domain is loaded), and then clicking on Input for as many files as are
needed to define all the structures mentioned in Chapter 11.2 By clicking on Trace in 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 either Interactive or 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, Execute can 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 15
Execution — controls behavior during execution, Chapter 7.3
Efficiency — controls behavior affecting efficiency, Chapter 15
Numerical — controls behavior affecting numericals, Chapter 18
I-Search — controls behavior affecting interactive planning, Chapter 3
Search Space — controls how many plans to find and how to search, Chapter 3
Printing — controls how structures are printed, Chapter 5
Drawing — controls what is drawn on each node, Chapter 4
Node Sizes — sets sizes of drawn nodes, Chapter 4
Node Colors — sets the colors for drawing each type of node, Section 4.7
Node Shapes — sets fonts and other parameters for drawing nodes, Chapter 4
Completion — controls completion of names being input, Chapter 9
2 Generally,
there is one master file that loads all necessary files. In Lucid and Allegro Lisp, the master file must use
eval-load instead of load to load other files, as described in Appendix H.
3 Customizations are often placed in input files by setting the appropriate variables in the Lisp file globals-customize,
as described in Section 15.
11
Dictionary — associates dictionaries with the current domain, Chapter 9
ACT — controls translations to the ACT formalism, Chapter 8
Layout — changes layout of window panes in the GUI, Section 3.6.4
Colors — sets colors of window panes in the GUI, Section 4.7
Birds 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. Reset restores S IPE –2 to its initial state, destroying all structures that have been
created since the last reset. Input prompts for a filename and loads the specified file. The user may load
as many input files as desired without resetting S IPE –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 Plans removes 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 defining 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 the List and Print commands have several forms, depending on what is being listed or printed:
operators, problems, plans, plan decompositions, nodes, worlds, objects, and contexts. Objects refers
to classes and instances in the sort hierarchy. The List commands list the names of all such structures
known to S IPE –2, with the exception of nodes. There are generally too many nodes for a listing of them
all to be helpful. Instead, List Nodes prints a list of all the plan nodes in the particular plan selected
by the user. An additional command, List Files Input prints all the files that have been input using the
Input command. The Print 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 -> ACT command 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 S IPE –2 problem-solving algorithms:
Automatic — invokes automatic problem solving
Interactive — solves a selected problem under interactive control
Interactive-1 — expands a selected problem under interactive control for one planning level
Continue — continues interactively solving the current plan
Continue-1 — continues interactively expanding the current plan for one planning level
Movie-Mode — solves a problem while generating plan drawings at each planning level
Three commands create new plans or plan names by modifying existing plans. Abstract makes
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. Rename renames 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 the Print Plan command of the Domain menu
Print options — prints the plan with many options for controlling printing
Destroy — removes a plan from the list of recognized plans
Output — saves the entire plan to a file
Input — inputs a plan from a file
Add Goal — adds a goal to the current plan
Delete Goal — deletes a goal from the current plan
Add 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 commands Rename and Destroy also perform their respective actions on any existing drawing
with the same name. Destroy simply hides the plan from the GUI. Internal data structures are actually
destroyed only when the domain is reset, so a “destroyed” plan can still be accessed 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.
The Draw 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 the Drawing command
in the Profile menu, which is described further in Chapter 4, determine the form of the drawing. (As in
the Domain menu, Objects refers to classes and instances in the sort hierarchy.)
Select, Destroy, and Destroy-multiple perform the named actions on existing drawings. As described
in Chapter 4, New View permits 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). Rename allows drawings to be renamed. In
the case of plans and problems, the underlying S IPE –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 collections of drawings. These commands are documented in detail in the Grasper reference manual [2]. A
Grasper graph is essentially a collection of drawings that can be associated with a filename and saved
on disk. There are five commands that manipulate graphs: select chooses a graph; create generates a
new graph with a new filename; destroy removes an existing graph; input reads in a graph from a file;
and output writes 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 View cannot 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 drawing
Redraw — redraws the graphics pane
Reparse — reparses the underlying S IPE –2 structure into a new drawing
4 This
command is active only when SRI’s Cypress system is loaded.
Output command 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.
5 The
14
Backup — saves (internally, not to disk) a copy of the current displayed drawing
Revert — reverts to the most recently backed-up copy of the drawing
Rescale — rescales the current drawing
Hardcopy — draws the current drawing to a hardcopy output device.
The Browse command 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. The Redraw command is useful if the screen
contains garbage. Reparse is used when a S IPE –2 structure has changed since it was last drawn. For
example, a plan may be drawn before the plan critics are invoked. Clicking on Reparse after 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 the Printing 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-Ancestors prints 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 pane
Find-Edge — finds an edge in the drawing and highlights it in the graphics pane
Reshape — modifies the appearance of a node or edge
Reshape-group — modifies the appearance of a group of nodes or edges
Move — drags a node to a new location
Move-group — drags a group of nodes to a new location
Align — aligns nodes horizontally or vertically
Align-mode — selects mode to use for the Align command.
The Completion command in the Profile menu can be used to choose how the Find-Node command
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 commands Predecessors, 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 commands Resource, Argument, and Predicate allow 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 S IPE –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 the Predicate command 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’s clim.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, metacontrol-Y will recall the last input, and meta-Y can then be used repeatedly to yank previous inputs. On
Sun workstations, the Del key and not the Backspace 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 middleclick on the value and a cursor will appear and Emacs-style editing commands can be used to modify
the entry. Input must be 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 on Save Changes (or equivalent) at the bottom of the menu. Clicking
on Abort 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, input must not be terminated by the Return
key; hitting Return causes the menu to exit as if Save 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.
when keyboard input is expected.
7
Control-Z also returns to the top level if pressed
6 In CLIM 1, things are different, but fairly obvious. For example, “radio-box” choice are all displayed and can be clicked
to select.
7 In CLIM 1, because of a bug in CLIM, the user sometimes must next press some key (e.g., Rubout or any letter) with the
mouse 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 between 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 S IPE –2 is layered on top of a graphical editing tool called Grasper-CL. To understand 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 L ISP system developed at SRI for displaying and manipulating 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. S IPE –2 constitutes one such application, while the Act-Editor and P RS - CL are others.
The primitive building blocks in Grasper-CL are nodes and edges. Nodes and edges are displayed
as a combination of an icon and a label. 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. S IPE –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 a space. In S IPE –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 a graph. 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 the Output
command. It is important to remember that the term graph is never used to refer to an actual drawing
of a graph (e.g., the drawing of a plan is a directed, acyclic graph). Graph always refers to a group of
spaces associated with a file.
The user always works in a particular graph, 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 the Select command in the Drawings menu. If the user switches graphs, the
system will no longer know about drawings in the previous graph.
If a S IPE –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
Blocks World
Missionaries and Cannibals
Robot Planning
Tower-Of-Hanoi
Travel domain
Blocks World with fuel
File name
sipe:input;blocks.sipe
sipe:input;cannibals.sipe
sipe:input;robot;demo.sipe
sipe:input;tower-of-hanoi.sipe
sipe:input;travel;travel.sipe
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 S IPE –2 to generate and draw plans. It is assumed
that S IPE –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, S IPE –2 has sipe.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 the Drawings command in the upper part of the command menu; the Drawings commands appear in the command pane.
Click on the create command under GRAPH.
In response to the prompt, enter the name of the file in which the graph should later be saved (such
as "/homedir/examples.graph"). If desired, the prompt can be edited with Emacs-like
commands.
The next prompt asks for the name of a new space within that graph, type Foo.
S IPE –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 S IPE –2, and are useful as a tutorial.
Click on the Domain command in the upper part of the command menu; the Domain commands
appear in the command pane.
Click on the Input command, which prompts for a file name.
sipe:input;blocks.sipe, which is the initial default, and press Return.
Enter
Try various commands under List and Print. For example, click on List Operators and List 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 the
mouse to the Puton1 choice.
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 the Plan command in the upper part of the command menu; the Plan commands appear
in the command pane.
Click on the Automatic command, which brings up a PC menu. Click Do It to solve the first
problem.
After planning, a menu will appear. From the menu of choices for “Draw Plan Graphically”
choose “Use-Default”. Click Do It and a drawing of the plan will appear.
Click on the Movie Mode command, which asks for a problem to be solved. Select “Two Conj”
from the menu — this is the standard Sussman Anomaly.
S IPE –2 will draw partial plans and flash nodes as it plans. It will create five drawings and sleep
after each drawing for a few seconds.
Now we will generate a plan interactively, allowing more user control of the planning process.
Click on the Profile command.
Click on the I-Search command (for Interactive Search), which brings up a PC menu.
For the “Display option at each plan level” option, select “Draw” from the menu, then click Do It.
Other options allow user control of planning, but the blocks world has few choices. Later, in the
missionaries and cannibals problem, the “User chooses operator at each node” option is a good
choice for interactive planning.
Click on the Plan command.
Click on the Interactive-1 command, 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 get
some red block on another red block. This expands the plan one planning level and stops.
Continuously click on the Continue-1 command to expand the plan until completion. Two such
clicks 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 the Drawings command in the upper part of the command menu; the Drawing commands
appear in the command pane.
21
Click on the New View command, which brings up a PC menu. Click on the box for “Filter
Phantoms”, then click Do It. You will see a plan drawing that includes both the action nodes and
the 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 the New View command again, click on the box
for “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.
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.
Under Draw, click on the Objects command, 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 its
properties.
Under Draw, click on the World command, which brings up a PC menu. Click on the “Display
all predicates” option, and Do 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 the Select command and choose the drawing for the red-blue plan. You can drag the
mouse, or get the menu to stay with a sharp click on the command.
Click on the Node command in the upper part of the command menu; the Node commands appear
in the command pane.
Click on the Predecessors command.
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 the Argument command.
Enter R1 for the object to find, and the actions with R1 as an argument will be highlighted.
22
Click on the Print-Ancestors command.
Click on any node, or right click to abort.
Now, we will load the missionaries and cannibals domain.
Click on the Domain command.
Click on the Reset command, and continue holding the mouse down until it is over the confirmation that appears. Click on the second confirmation.
Click on the Input command. Enter sipe:input;cannibals.sipe using Emacs-like commands (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 the Search Space command, which brings up a PC menu.
For the “Search space for multiple plans” option, select “Gensym-names” from the menu, then
click Do It.
Click on the Plan command.
Click on the Automatic command, which brings up a PC menu. Click Do It to solve the first
problem. S IPE –2 will search the entire space and find four plans.
Click on the Drawings command.
Click the Draw Plan command, and select one of the four plans, then click Do It.
Click the Draw Plan Decomposition command, then click Do It, and you will see how the plan
was 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 the Search Space command, which brings up a PC menu.
For the “Search space for multiple plans” option, select “No” from the menu, then click Do It.
Click on the I-Search command.
23
Select the “User chooses operator at each node” option and the “Check preconditions before user
chooses operator” option (both are in the top group), then click Do It. The latter option removes all
inapplicable 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 Layout and select the last choice, “Top Menu with Lower Interactor and Choice”. The
command menus will now be pull-down menus, and user choices will appear in the pane at the
lower right.
Click on the Plan button at the top.
Click on the Interactive command, which asks for a problem to be solved — simply click Do It.
The interactive planning menu presents many choices. Continuously click on the PLAN NEW
LEVEL choice to expand the plan.
Whenever a choice appears in the choice pane (lower right). Select the operator you wish to
apply by clicking on it and then clicking Select at the bottom of the choice pane. You can also
click Describe to see the operator drawn before you make a choice. If planning continues without
offering you a choice, it means that only one operator was applicable.
At any point, in the interactive search menu, you can select QUIT to stop planning (e.g., to use
the GUI before continuing) or Finish planning automatically to let S IPE –2 finish what you have
started.
To continue after quitting, click the Plan button at the top, then the Continue command.
If you make the right choices, S IPE –2 should find a final plan. If not, you can interactively direct
backtracking by invoking the Interactive command and selecting the “Backtrack in last plan” option.
The Finish planning automatically option may become more appealing.
To stop planning, select Exit or Kill Lisp Process from the Application menu.
2.3 Running SIPE-2 without the GUI
S IPE –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 S IPE –2 in such a window. In CLIM, the CLIM
root window must be initialized, so first call (run-sipe) and then exit. S IPE –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 efficiency
Planning Profile — sets a variety of parameters controlling S IPE –2
Trace Profile — sets flags for controlling what S IPE –2 prints
Load File — loads an input file (or any other file)
Reset Sipe — restores S IPE –2 to its initial state
Execute — executes an existing plan
Interactive Solve — solves a defined problem under user control
Automatic 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 before
Lisp — enters a Lisp break point
Help — prints a summary of all options.
Typically, a planning session begins by clicking on Reset Sipe, and then clicking on Load File for
as many files as are needed to define all the structures mentioned in Chapter 11. By clicking on Trace,
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 either Interactive Solve or Automatic Solve. Display can be
used to inspect the planning results and Execute can 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. S IPE –2 provides automatic 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 the Solve command in the Plan menu invoke the S IPE –2 problemsolving 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 Abstract makes 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 on Regroup makes 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 either Automatic, Interactive, Interactive-1 or Movie-Mode generates a solution for a
problem that has not been previously solved. The commands Continue and Continue-1 continue problem solving on a partial plan. The Automatic and Movie-Mode commands 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 appli26
cations, allows a human expert to guide S IPE –2, and allows the system to address larger problems that
may initially be beyond the capabilities of fully automatic planning techniques.
While S IPE –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 the Planning command in the Profile menu and makes
use of the replanning capabilities described in Chapter 7.
3.1 Naming Plans and Contexts
S IPE –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*. S IPE –2 clears
*current-plans* each time a search is initiated and sets the variable whenever a plan is generated.
S IPE –2’s search algorithms have been built on basic mechanisms that facilitate the ability of users
to encode their own search strategies. A context is 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, S IPE –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 the Trace command 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 clicks Trace 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 after each planning
level. Tracing domain definition is useful for finding syntax errors as the system prints notices for each
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, controlled 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 is T (default is NIL), 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 is T (default is NIL), 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 is T (default is NIL), 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 debugging. 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 S IPE –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
The Movie-Mode command 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. S IPE –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, and Efficiency
— can be used to customize the planner before commencing planning. The Planning and Efficiency
commands are only for programmers and are described in the chapter on advanced customizations
(Chapter 15). The following variables, interactively set with the I-Search and Search Space commands,
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 of auto-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
are T, NIL, and :gensym-names. A value of T means the user is asked for a name for each plan.
[Variable]
number-of-answers
If multiple-answers is non-nil, this variable indicates the number of plans to be found. Legal
values are an integer or NIL. NIL causes all plans to be found by exhaustively searching the search
space.
*default-depth-limit*
This is an integer specifying the default depth limit used by the automatic search.
[Variable]
*time-limit*
[Variable]
This is the default time limit in seconds (see function solve for details). The default value, NIL,
indicates no time limit.
3.4 Automatic Solving
The Automatic command 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 on Automatic. The first few choices are arguments
to the search algorithm, while the remaining choices provide easy access to certain Profile-menu commands. 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 the Advisable 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 is NIL, 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 commands Continue or 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 is find-plan-for-plan-name.
The function solve-act takes a task expressed as an Act and generates a plan (or plans) for
that problem. The function generate-plan takes the name of a S IPE –2 problem and generates a
plan (or plans) for it. (It is called by solve-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
S IPE –2. Both functions convert the problem to a partial plan and call solve.
The function solve takes a S IPE –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 for solve.
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 generation 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 for each plan
is generated (planning continues without user interaction). If T, 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 or NIL and is only used if multiple-plans is non-nil. The
system will stop when this many plans have been found. If the value is NIL, the entire search space will
be explored when multiple plans are requested.
32
Partial-plan-at-level is an integer or NIL. 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
Continue and Continue-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 coarsegrained for fractions of a second, and cannot guarantee returning within a certain time.
3.5 Controlling the Solution Process
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 accomplishing such control: (1) giving an operator prioritization function to solve, (2) providing a variable
instantiation function, and (3) using the Advisable Planner. These options affect both automatic and
interactive planning. Advanced programmers may want to implement their own search control algorithms.
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*
This value is the name of a function to call for instantiating variables.
[Variable]
This function should take 3 arguments: a varptr (see Section 13.3) for a variable, a list of varptrs for
instances 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 this
implies acceptance of any constraint violations incurred by choosing such an object. (Remember, the
planner 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 variables
will 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 the
latter 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 proceeds
normally.
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 this
call to critics/expansion. No permanent constraint limiting the variable to this set of values will
be posted. Thus, the result of this returned value will have no effect unless either the user is
choosing instantiations interactively, or constraints on other variables force an instantiation during
this critic/expansion.
3.5.2
The Advisable Planner
S IPE –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 guidance 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 S IPE –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: role and method. 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 URL http://www.ai.sri.com/˜myers/projects/ap.html provides information
about the Advisable Planner, including a manual for its use.
3.6 Interactive Solving
S IPE –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 information relevant to planning decisions.
The Interactive command 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 the Continue command to resume solving later. The Interactive-1 and Continue-1 commands
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. The Continue-1 command 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 S IPE –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, S IPE –2 does not guarantee
completeness without duplication if the plans contain parallel actions (it does for linear plans). Heuristics 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 S IPE –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 interaction can be chosen by using the I-Search command in the Profile menu, or by selecting the Set 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, S IPE –2
asks for a problem to solve, asks whether to draw the problem, and then displays the top-level interactive search menu, which then pops up at the beginning of each planning level. The user selects Plan
New Level each 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, S IPE –2 will print a notice that a solution has been found, and Quit 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 appendices of this manual and is distributed with SIPE –2 in the files sipe:input;blocks.sipe,
sipe:input;cannibals.sipe, and sipe: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. Clicking on either Interactive-1 or Continue-1 initiates 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 clicks Continue-1 to initiate the next planning level. Thus the fast search consists of repeatedly clicking on Continue-1 without
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 click Redraw Current Plan in the interactivesearch 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. The Draw Plan command 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. An expandable plan is a plan object for a partial plan, i.e., a plan that is ready to
1 This command has been added since Figure 3.3 was saved. Unfortunately, CLIM menu-choose windows cannot be saved
as 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 selfexplanatory; Set Options invokes the I-Search command 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, S IPE –2
begins expanding the current plan. These commands are summarized below:
Retry Old Choices — backtracks to last unexplored choice and tries it
Plan New Level — expands a new level
Apply Critics — applies all critics immediately
Check Constraints — invokes resource allocation and constraint satisfaction
Finish Planning Automatically — invokes the automatic search on a selected partial plan.
Figure 3.4: Check Constraints Menu
Two items require explanation. Retry Old Choices invokes backtracking and highlights the nodes
that are backtracking choices, after allowing the user to choose the plan level for backtracking. Clicking
on Check Constraints displays 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, S IPE –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 GUI
Suspend to Display — allows full use of the GUI while suspending problem solving
Lisp — enters a Lisp break point immediately.
Only Suspend to Display requires more explanation. This command creates an additional S IPE –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 on Exit 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 variable choices. These are both
set to NIL whenever a new problem is started. However, their old values are pushed onto the variables old-plan-levels and old-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 the I-Search command in the Profile menu
or by selecting the Set Options command 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 the expand-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 instantiation of 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 choosing yes, the user selects from a menu of names. By choosing mouse, 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.
2 This
option decreases efficiency for two reasons: (1) often the system checks only one precondition (for the chosen
operator) instead of all of them, and (2) matching will be performed again when the operator is actually applied. In domains
where operators have preconditions containing 20 predicates and plans may be hundreds of steps long, a precondition can take
a 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 conflicting 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 S IPE –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 the Search Space, Trace, and Planning commands. 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 the I-Search command are listed below.
Their default values are NIL unless otherwise specified. Their values can be set in an input file to
40
customize problem solving:
[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.
[Variable]
interactflg
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 to
user.
[Variable]
*user-chooses-goal*
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 of
asking 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 resource
conflict.
3.6.4
Window Layouts with Choice Pane
S IPE –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 the Layout command 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 missionaries 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 the Select command selects the operator. Clicking on Describe describes the currently
41
Figure 3.7: GUI with Choice Pane
selected choice and (be default) draws it in the graph pane. Clicking on Select will then restore the plan
drawing. The interactive search provides options with many choices — these can be selected by clicking
on Options. Clicking on Abort aborts problem solving.
The following variable controls the Describe command 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 a
pop-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
The Add Goal command first asks the user to enter a goal expression and then asks the user to click
on the node that should precede the goal. The Delete Goal command 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. The Modify
command in the Domain menu can be used to change the predicates in a given world description. The
Add Facts command 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. Unlike Modify, Add Facts does
not change the knowledge base; rather it adds a mother.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 Facts invokes 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 after Add Facts is invoked.
Advanced concepts: A function, what-if, provides programmatic access to the capabilities in
the Add Facts command. 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 problem
recognizer and replanner to modify the plan to be valid in the new world. The auto-replan variable
controls whether the replanning is done in movie mode, interactively or automatically. Preds can
be a list of S IPE –2 predicate structures or a list of expressions to parse, e.g., (not (on a b)).
The replanner sets the variables *current-plan*, lastplanhead, and answer-names to the
resulting plan, see Chapter 7.
3.8 Intermingling Planning and Execution
S IPE –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 S IPE –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 token delay in the description of a node in
the plot of an operator instructs S IPE –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 token delay-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 S IPE –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 S IPE –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 S IPE –2 manipulates 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 S IPE –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
Efficiency command 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-brothergoal (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*
Value is a list of operators after which to apply CBG critic, T for all.
[Variable]
*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 expanded 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 S IPE –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.
Phantomize
Goals
,,
,
@@
R
@
Apply Operators
to Nonprimitive
Nodes
Copy Other Nodes,
Recalculate
Deductions
@@
@R,
,
,
ConstraintSatisfaction
Critic
-
Phantomize
Goals
-
6if primitive plan with
new instantiations
-
Resource
Critic
- ProblematicInteraction 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 without applying an operator). It then applies an operator to each node in the plan that requires further specialization (i.e., to each nonprimitive goal, 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 still accessible
through its context. No backtracking points are kept for variable instantiations or the addition of 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 the Draw command and shows the types of output they produce. Ways
to customize the appearance of drawings are also described. The Profile-menu commands Drawing,
Node Sizes, Node Colors, and Node Shapes allow customization of drawings, although the defaults are
appropriate for most domains. Each of the first three has its own section in this chapter. The Node
Shapes command allows setting of Grasper node-shape parameters, as described in the Grasper manual
[2]. Primarily, Node Shapes allows the setting of fonts and highlighting styles.
4.1 The Drawing Profile
The Drawing command in the Profile menu brings up the menu in Figure 4.1. The first choice regards
using defaults for drawings. If the choice is yes, the system never displays the menu for labeling
and filtering a plan drawing (Figure 4.2). If no, 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-primitive goal
nodes are turquoise hexagons, precondition nodes are brown rectangles, phantom nodes are gray
rectangles, split and join nodes are gray triangles, non-primitive process 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.
The Draw 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 Problem and Draw 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 on New 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 on New View, there will also be a choice of plans to draw.
The New View command 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, S IPE –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 the New View command or the Drawing command 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:
[Variable]
expand-y-layout
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 S IPE –2.
The last item in the menu forces reparsing of the plan drawing. Since drawing a large plan can take
time, S IPE –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 the Reparse command in the Drawings menu.
4.2.2
Plan Decompositions
The Draw Plan Decomposition command 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 the Draw Plan Decomposition command 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 precondition 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
The Draw Operator command 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 the New View command.
The Draw Operator-Graph command 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. S IPE –2
provides three methods for specifying the root of the operator graph (on a menu that appears when
Draw Operator-Graph is 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.) Class sort-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.
The Draw Operator-Graph command is particularly useful for understanding the structure of a set
of operators that have been written by someone else.
4.2.4
Initial World
The Draw World command displays the initial world predicates graphically. It lets the user select specific 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.
The Draw Objects command 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, the Print Object command can be used
to print information about the size of classes before drawing them (see Chapter 5). S IPE –2 generates
a root node which is pointed to by the global variable sort-hierarchy. Any input class that has
no parent becomes a subclass of this root. Figure 4.4 shows the result of drawing sort-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 decompositions, which otherwise would have their topmost or leftmost nodes too spread out for easy
visualization. The Browse command 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
Browse command. 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 a browsing 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 the Browse command 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. The Birds Eye command in the Profile menu controls what is displayed in the birds-eye
window.
The user can manipulate the birds-eye window when in birds-eye mode, which is entered by middleclicking 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 viewport
within the entire graph. The user can reposition this rectangle to a new position in order to scroll
the graph pane. After selecting this menu item, left click in the background of the birds-eye
window 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 yet
implemented. They should not be used.
4.5 The Node Sizes Profile
The Node Sizes command in the Profile menu controls the size and spacing of nodes in drawings.
Five sizes are already defined in S IPE –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.
The Node Sizes command gives a menu for changing these numbers for the five system sizes, and choosing which size will be the default. (The user can define his own size by adding its name to the list sizes
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.
The Rescale command in the Drawings menu is useful for shifting, shrinking or expanding a drawing
layout in either the horizontal or vertical direction, or both. The Magnify 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 the New View command affect the node labels.
The size for one drawing can be changed with the New View command or the default size can be
changed with the Node Sizes command. Larger sizes use more spacing during layout and larger
node 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, using
the Node Sizes command in the Profile menu.
The Rescale command can shift, shrink or expand a drawing layout in either the horizontal or
vertical direction, or both.
If the label font is too small or too large, it can be changed with either the Node Shapes command
or the Magnify command. With the latter command, all magnifiable drawings (which include all
S IPE –2 drawings) in the current Grasper graph are expanded to any of a number of prespecified
font sizes. This command also affects all future drawings in this Grasper graph, so one must
return the size to ”normal” to get the default drawing behavior on future drawings. Magnification
imperfectly 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 variables from the New 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. If T, only the id is printed.
If NIL, only the name is printed. If :both (the default), both the name and id 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 abbreviations: 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 S IPE –2 input file.
*abbreviations*
Value is an a-list of object names and their abbreviations.
[Variable]
*attribute-names*
Value is an a-list of sort-hierarchy attribute names and their abbreviations.
[Variable]
*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
S IPE –2 allows the specification of parameterized textual descriptions for goals, actions, and operators. 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 variable name-flag,
which can be set by the New View command or the Drawing Profile command. The value of
name-flag should be :text-description to use documentation strings, and normally arguments would not be printed in this case, because the documentation strings include them. Documentation 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 describing the world state, *goal-documentation-strings* stores documentation strings for predicates 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 the Draw
World command or during drawing of plans, the system uses Lisp’s format function applied to the documentation 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")))
’((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 Ã")
58
(row-2-m (5) "Row 2 missionaries˜% to Ã")
(row-2-c (5) "Row 2 cannibals˜% to Ã")
(row-1-c (5) "Row 1 cannibal˜% to Ã")
(row-mc (5) "Row 1 cannibal and 1 missionary˜% to Ã") ))
The following variables are useful for customizing the textual output of S IPE –2. Setqs for these
variables can be put at the end of any S IPE –2 input file.
*documentation-strings*
[Variable]
Value is an a-list of a predicate name and printing instructions, used in printing predicates describing
the world state.
*goal-documentation-strings*
[Variable]
Value is an a-list of a predicate name and printing instructions, used in printing predicates in plan
nodes.
*action-documentation-strings*
[Variable]
Value is an a-list of an action or operator name and printing instructions, used in printing process
nodes in a plan.
4.7 Colors in Drawings
In all drawings, S IPE –2 uses colors to distinguish different types of nodes. In S IPE –2 plans, all open
nodes, i.e., those needed expansion at next level, whether goal, process, or choiceprocess, are
in turquoise, primitive actions are in blue, phantom nodes are in gray, and precondition 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.
S IPE –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 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 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 order of magnitude. Drawing is still fast for plans with dozens of nodes, but for plans with hundreds 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 the Node Colors command 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 the Colors command. 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 graph grasper: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). This
is useful for setting colors in an initialization file. The menus used in Node Colors and Colors 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 dumps
for printed documents.
default-colors
This function restores S IPE –2 to its default colors.
[Function]
4.8 Customizing Node Shapes
A Grasper node shape defines how a node is drawn (color, label, icon, and so forth). S IPE –2 has
node shapes defined for each type of node and supports the following capabilities:
1. Other applications building on top of S IPE –2 and defining their own special node shapes for nodes
with particular properties. Special node shapes are used for replanned and advised nodes within
S IPE –2.
2. Users interactively modifying the node shapes (with the Node Shapes command in the PROFILE
menu), 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 S IPE –2 application in the GUI.
Programmers familiar with Grasper can use the following variables to customize the drawing of certain nodes, as is done in the multiagent version of S IPE –2 (see the file mpa-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.
S IPE –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 dotted
pairs. The car of each pair is the name of a predicate (L ISP 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 Grasper
node shape to be used for display of nodes satisfying the predicate. If a node matches more than one
predicate, 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 time S IPE –2 is reset. It is assumed
node shapes not on this list are specific to domains. Setting this variable changes node drawings
across 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, S IPE –2 defines different shapes for monochrome monitors than for color monitors
(distinguished by the variable *MONOCHROME-MONITOR?*). S IPE –2 therefore calls functions to define the shapes when it first enters the S IPE –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.
The S IPE –2 function set-default-node-shapes should be used as a model. This function is
called when the S IPE –2 application is first selected in the GUI.2 This function can also redefine system
default 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 from
defaults specified in the previous function. The S IPE –2 function
set-node-shapes-from-defaults should be used as a model. This function is called
immediately after set-user-default-node-shapes, and when the user interactively restores
default node shapes.
*set-node-shapes-function*
[Variable]
This variable is used to replace system default node shapes with custom shapes. The value can be a
function of no arguments that defines defaults for all node shapes, both domain-specific and all those
used by S IPE –2.
1 The
shapes default to those for a color monitor, so the GUI can be used to draw plans without ever entering the S IPE –2
application in the GUI for color monitors.
2 This selection happens whenever S IPE –2 is selected from the Application menu, or when the function (run-sipe) is
called. However, creating the GUI with another function (such as run-grasper) will not select S IPE –2 or update its node
shapes.
61
4.9 Miscellaneous Customizations
The Rescale command in the Drawings menu is useful for shifting, shrinking or expanding a drawing in
either the horizontal or vertical direction, or both.
S IPE –2 allows customization of flashing of nodes. When requested in the planning profile or interactive 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. The
value of this variable should be T, NIL, or a list of two numbers. The first number is the number of
times a node is flashed, and the second number is the length in seconds of each flash. A value of NIL
inhibits flashing, and a value of T 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 S IPE –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 the Print command and shows the types
of output they produce. Before printing, the Printing command in the Profile menu allows setting of
defaults for controlling how much information is printed for each 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 the Print 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
Object pops up a menu that has several options for printing information about the sizes of classes in the
sort hierarchy. Print Node allows printing of almost any internal data structure, which can be useful to
the programmer as described in Section 5.4. Clicking on Print 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-window that can be used inside the GUI to direct output to the *debug-io*
stream, which if often the Emacs window from which S IPE –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.
S IPE –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 S IPE –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 on Display in the top-level menu. Inside the GUI, these functions 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 corresponding Print commands in the
Domain menu. Name Abstractions and Regroup Parallel are the same as Abstract and Regroup of the
Plan menu.
The following global variables allow access to system structures:
lastplanhead
Value is the last planhead node used by the planner.
[Variable]
operators
Value is a list of operators in the domain.
[Variable]
problems
Value is a list of problems in the domain.
[Variable]
state-rules
Value is a list of state rules in the domain.
[Variable]
causal-rules
Value is a list of causal rules in the domain.
[Variable]
1 On
Suns, the CLIM root window must be initialized, e.g., by calling (run-sipe) and then exiting.
65
[Variable]
init-operators
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 following 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 operators
but not plans) are printed to a browser with hyperlinks to other S IPE –2 objects (currently only
Netscape is supported). Plans are printed to a (CLIM) pop-up window. If the value is any other non-nil
value, large texts are printed to a pop-up window. If the value is NIL, all texts are printed to the Lisp
listener.
*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 are
printed as directed by *print-to-popup*. If the value is anything else, the operators are drawn in
the graph pane (thus replacing any plan drawing that existed).
big-lnlength
This variable is the line length for printed text. The default is 72.
[Variable]
vp-print-id
[Variable]
This variable controls how uninstantiated variables are printed and drawn. If T, only the id is printed.
If NIL, only the name is printed. If :both (the default), both the name and id 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. The
default 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. The
default is "-install".
The following variables can match the size of pop-up windows to a given monitor:
*popup-text-size*
The default is :normal. Any legal CLIM font size can be used.
66
[Variable]
*max-popup-width*
The default is 1050.
[Variable]
*max-popup-height*
The default is 830.
[Variable]
5.4 Printing Internal SIPE-2 Structures
Advanced Concepts: This section describes capabilities of the Print Node command and should be
read only by programmers.
The Print Node command 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 S IPE –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 its id 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 listener). The value of plan-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 defaulting plan-con to
something 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*.
[Function]
dnode
This function bring up a menu asking for the node name and output destination. It calls dispnode or
dispnode-popup with the given node.
display-in-browser node-name-or-url &key executable node-action
67
[Function]
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 a
browser. If node-name-or-url is a symbol bound to any type of S IPE –2 object, this function will
print 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 tries
to display remotely in an existing browser, if that fails, a new browser is started.
The printing can be modified by node-action, which defaults to “Inspect” causing the standard
printing of the object. Another action is “Derivation” which prints the derivation of a plan node, showing
goals 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 function dnode can be invoked by clicking on Node in 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 several pred constraints which constrain it to be either conf-door1 or conf-door2,
and finally an instan 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 of NIL. The
variable will then have no instantiation in the given context. If the context had been given as NIL 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 S IPE –2 Web Server makes a small subset of the functionalities of S IPE –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 one
node 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 parallel 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 S IPE –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 S IPE –2 Web Server is based on
two additional applications CL-HTTP and CWEST, which can be distributed with S IPE –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 S IPE –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 to access and are not normally distributed with S IPE –2. The latter only includes non-military domains and can be accessed 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 keyword sipe-domain can
provide the name of a known domain which is loaded initially. The port can be specified, but defaults
to 8000 if public is t, otherwise a different port. If public is non-nil, only the non-military subset of
S IPE –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 DOMAINNAME
and HOST. Alternatively, the host and domain keywords can provide these values. If the keywords
are 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
start-ws &key sipe-domain public port
[Function]
[Function]
There are two shorter names for invoking a Web Server. They call start-www-server with the
given keywords.
[Function]
[Function]
stop-ws
stop-www-server
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 S IPE –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 click Set Node-click Action to send the action to the Web Server.)
Welcome page: enter your name and click Enter SIPE-2.
Select domain page: click Use Current Domain if there is one, else pick a domain. You can only
change domains if you are the only user. Missionaries-and-Cannibals is recommended for quickly
checking things out. For military plans, choose Air-Campaign-Planning-Granola, but solve only
the 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 problems 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, the
objects 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 sure
Java-script is enabled. You can also try the browser’s back button. If you cannot get back, click
Return to Commands, then execute Draw Plan or Decomposition to restore the plan drawing.)
Click Return to Commands. Make sure the plan is drawn again.
Commands menu: Select Derivation as the node-click action, then click Set Node-Click Action.
Click on nodes in the plan. You will see how they were derived, going back to the most abstract
planning level. Click on hyperlinks to see goals or operators used for expansions.
Commands menu: Now select Draw Plan or Decomposition and click DO IT/Plan-draw.
Draw menu: Pick the plan you want and click Browse Plan Decomposition. This draws the
topmost goals that were expanded to produce the plan. This also sets the node-click action to
Expand.
Click on the fringe nodes with bold labels to further expand the decomposition. Clicking on
already expanded nodes will Inspect them. Optional: set the node-click action to Contract, and
click on a node to contract its expansion.
Click Return to Commands.
Commands menu: Now select Draw Objects Hierarchy and click DO IT/Plan-draw.
Draw Objects menu: In military domains, click Browse Objects Hierarchy. In smaller domains,
you can click Draw Objects Hierarchy.
Again click on nodes to expand, contract, or inspect them, after selecting the desired node-click
action.
Click Return to Commands.
Commands menu: Now select Draw KB Operator Graph and click DO IT/Plan-draw.
Operator Graph menu: for small domains, click Draw Operator Graph. (Optional: select option
for whether to draw purposes of operators.) For the military domains, this will take some time,
so either: click Browse Operator Graph, or select Selected Operator under ”roots”, select an
operator (in ACP, use Devastate-network or Add Dedicated Escort, then click Draw Operator
Graph.
Again click on nodes to expand, contract, or inspect them, after selecting the desired node-click
action.
73
Chapter 7
Plan Execution and Replanning
S IPE –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. S IPE –2’s replanner responds
to unexpected events by revising the plan to respond to the current situation. While S IPE –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, S IPE –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 the Add
Facts command and the what-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
Unexpected Situation
JJ
,
,
JJ
,
^ ,,
new plan
Execution
Monitor
, ,,
,
, ,,
,
,
,
@@
plan and
situation
Problem
Recognizer
problems
-
@@
@R
Replanner
-
Planner
,,
,plan with
,
unsolved goals
,,
?
Replanning
Actions
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
the problem recognizer, which returns a list of all the problems it detects in the plan. The replanner
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 S IPE –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
The Execution command 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 predicates 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 S IPE –2 to use the value
of the variable *unexpected-predicates* as the list of predicates. This variable is set to NIL
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 programmers 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 to process nodes, which specify a single operator, when
the precondition of that operator is no longer true. These options control whether such a process node
will be replanned (i.e., its operator reapplied) or whether a higher-level goal will be replanned. Nodes
involving numerical level 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 a process 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 such process nodes. For process nodes that were introduced to solve
numerical level predicates, No and Yes select the same two behaviors as for non-Level nodes, but
there is an additional option, Delete, which is the default and will replace the process node with a
primitive no-op action whenever the node is being used to phantomize a level predicate. The level
phantom will become a goal, and its solution should achieve the effect of the deleted process 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.
S IPE –2 provides a capability for an external execution module to provide information to the execution monitor. Setting *external-executor* to T causes sipe to write executed plans to
user::sipe-output and get unexpected predicates from the stream user::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 Section 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 variables auto-execute and auto-replan, described below, can select
this option. S IPE –2 normally refuses to execute plans with open nodes (e.g., unsolved goals). This can
be done by setting the auto-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 is T (the
default) 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 to user::sipe-output and get unexpected facts from
user::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 wedge
in the plan (generally to reachieve a failed EFFECT at the failed NODE.) A root with multiple
applicable operators is desired so the planner can get a different plan. This variable is always used
when NODE is of type Process or Executed. When NODE is of type Precondition, this variable is only
used 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 is
used. The value can be a keyword (denoting an algorithm), a node, a predicate, or a function. These
varied 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. If
the value is :effect-higher, the root is an ancestor whose goal is EFFECT and with multiple
operator choices. If there is only one operator choice for EFFECT, then go up to the next higher
ancestor with multiple choices. If there is no such goal node for EFFECT, the replan will fail. If the
value is :effect-any, the replanner first uses the algorithm for :effect-higher, and if no root
is 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 is
not 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-any
algorithm, but with the given predicate for EFFECT. If the value is the name of a function of two
arguments, 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. The
default value is NIL. If the value is :replace, all non-executed nodes in the replan wedge are
removed from the plan when an action does not achieve its effects. If the value is :replace-all, all
nodes (including executed nodes) in the replan wedge are removed. If the value is :reachieve, the
replanner will attempt to reachieve the goals (at the replan root) on the same objects, without deleting
any nodes. Use :replace and :replace-all to force a repaired plan to be as different as
possible. A value of T is equivalent to :replace.
78
auto-replan
If T, replan using automatic search with defaults without printing result,
if :interactive, draw/print plan as directed by fast-interactive-search,
if :movie, replan in movie mode as directed by auto-interactive-search, and
if NIL (the default), use menus to query the user.
[Variable]
auto-execute
[Variable]
If NIL (the default), do not execute partial plans and interact with user. If T, do executions without
asking user to choose nodes or see replanning result. If :opennode-ok, execute goal and
non-primitive process nodes in plan.
*retry-processes*
[Variable]
This variable applies to process nodes not introduced by level goals. If NIL, do not replan
process nodes whose preconditions are false. If T, replan them (hope for match with different
instantiations).
*retry-level-processes*
[Variable]
This variable applies to process nodes that are introduced by level goals. Boolean values have
the same meaning as for *retry-processes*. If the value is :delete (the default), replace the
process with a *removed-for-level* node whenever it is being used to phantomize a level
goal.
perfectworld
[Variable]
If T, the Execution Monitor never pauses to accept unexpected occurrences, assuming that actions are
always executed perfectly. The default is NIL.
7.3 Executing a Plan
The execution monitor is invoked by clicking on Execute in 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, S IPE –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 of each of
the nodes before choosing, reset the perfectworld 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 from user::sipe-request or standard input. The expression read is parsed
and used to set *unexpected-predicates*. The expression should either be the symbol quit
or a list whose car is the symbol executed, 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. Any
nodes in the list exceptions are left unmodified. However, this does nor restore the initial world
model 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. S IPE –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 the Node
80
Colors and Node Shapes commands) 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 S IPE –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.
Numerical level predicates (see Chapter 18) require special treatment during replanning. It has
been common in S IPE –2’s domains of application to use numerical level predicates recursively to
accumulate a certain quantity of some resource. This results in the general case of N actions that together
make the level goal true, i.e., the actions phantomize the goal. Thus, several actions that produce or
consume quantities will phantomize such a goal by being ordered before the level phantom. The
replanner, therefore, removes all such orderings to a level 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 a process
node is no longer true. The replanner must decide whether such a process node should be replanned
(i.e., its operator reapplied) or whether a higher-level goal should be replanned. Replanning a process
node is desirable when the same operator would match with different instantiations. The default is to
not replan process 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 such process nodes that were introduced to
solve numerical level predicates.1 A process node that (1) was introduced to solve a level predicate, and (2) phantomizes a level predicate, occurs whenever a level predicate is being used recursively to accumulate a certain quantity of some resource (see Section 18.5.2). When such a process
node has a precondition that is no longer true, the replanner replaces the process node with a primitive no-op action. The level phantom becomes a goal, and its solution should achieve the effect of
the deleted process node.
1 This
is controlled by the *retry-level-processes* variable.
81
This algorithm is justified as follows. Of the N actions achieving the level 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, S IPE –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, S IPE –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 token delay in the description of a node in the plot of an
operator causes S IPE –2 to avoid planing any such goal or action until a plan suitable for execution has
been generated. Alternatively, the token delay-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 S IPE –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 the delay 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 S IPE –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 S IPE –2 planner has been used extensively in many domains, which has resulted in robustness 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
S IPE –2 can interact and cooperate with the following systems:1
GKB-Editor — for graphically browsing and editing the sort hierarchy, and for browsing plan
decomposition drawings.
Act-Editor — for graphically displaying, editing, and inputting plans and operators.
P RS - CL — for executing S IPE –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 the Modify command 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 S IPE –2 can resume.
S IPE –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 S IPE –2 but is not loaded as part of S IPE –2. P RS - CL, Gister-CL,
and Cypress are not distributed with S IPE –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.
1 S IPE –2,
P RS - 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 knowledge provided by the user, e.g., plan fragments and operators, as Acts. Acts are used by both the S IPE –2
planning system and the P RS - 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 S IPE –2. The ActEditor has its own manual [10], and S IPE –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 a Verify 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 S IPE –2 is translated to ACT. This information may be useful for an ACT user trying to understand S IPE –2 syntax or a S IPE –2 user trying to use
the Act-Editor.
8.1.1
Translation From ACT
There are -> SIPE commands in the GRAPH and ACT menus of the Act-Editor, which translate sets
of Acts or individual Acts, respectively, into a valid S IPE –2 input file that conforms to the syntax
specifications provided in this manual. This file is saved to disk, but not loaded into S IPE –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 the ACT 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 S IPE –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 precondition 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 translation. 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 selected, but are useful to an executor which can provide such knowledge itself in certain domains, e.g.,
when P RS - 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 all command 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 S IPE –2 domain is known to be correct;
otherwise, the Verify command 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 -> ACT command
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.
The ACT Options command 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 -> PRS command
does the same translation as -> ACT and also loads the Act into P RS - 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 S IPE –2 sort hierarchy graphically, saving it out to a file that can be
loaded into S IPE –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 decomposition
drawing.
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 Connectivity) for all knowledge-base interactions.2 S IPE –2 now supports OKBC for its sort hierarchy, thus
allowing use of the GKB-Editor. In theory, this also allows S IPE –2 sort hierarchies to be stored in any
2 In
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 efficiency, so the distributed S IPE –2 system does not use OKBC internally. Any OKBC-conversant frame
system can access S IPE –2 hierarchies without knowing the internal representation.
The GKB-Editor is not loaded when S IPE –2 is loaded. It can be loaded by evaluating (load-gkb)
after loading S IPE –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 S IPE –2.
Invoke the GKB-Editor on the current sort hierarchy by clicking the Modify command in the
Domain menu. Then select Edit sort hierarchy using the GKB-Editor and the
system will create a KB for the sort hierarchy. To create a new sort hierarchy, do this with
no domain defined. (The sort hierarchy always has some required classes that are used by the
system.) The system may query the user for a KB name and filename and provides standard
defaults using the variable *domain-name*.
In the GKB GUI, select Browse Class Hierarchy in the View Menu. (This switches the GUI from
displaying its previous drawing to drawing the KB just defined.) Click middle on a node to expand
it, 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 Contents
command 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 Editor
GUI will appear. Its Slot and Value menus are used to edit slots and their values. In the Slot
menu, the Add Template Slot command is used to add a slot to a class, while the Add Own Slot
command 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: any
type component given for the filename is replaced.) The .sipe file is in SIPE –2 syntax and can be
read into S IPE –2 to define the sort hierarchy. The .lisp file contains a list structure that compactly
represents the hierarchy. The .lisp file can be converted to a .sipe file (e.g., after editing it) with
the function convert.
The user can browse the sort hierarchy of an existing domain simply by loading the domain and
using the Modify command. 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 S IPE –2 or the
GKB-Editor. Browsing in S IPE –2 allows all the standard options for what is displayed for each node.
Browsing in the GKB-Editor does not support S IPE –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 S IPE –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
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 the Modify as
described 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 the
port.
Anyone on the web can go to this URL and use the GKB-Editor to browse this KB (this is single
user – 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
The GKB-Editor can be run on an existing KB without going through the S IPE –2 GUI (although
S IPE –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 S IPE –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
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 S IPE –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, S IPE –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 S IPE –2 Reset command 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*
Value is the KGB object for the KB of the current sort hierarchy.
[Variable]
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 the
GKB-Editor with subsystem :sipe is not loaded, a message (describing why no KB was created) is
printed. Name is any symbol and becomes the name of the new KB. Filename is a file where the the
sort-hierarchy will be written if a Save command is issued in the GKB-Editor.
89
8.3 Cypress Systems
S IPE –2 and SRI’s reactive control system, P RS - CL, are capable of integrated planning and execution
with asynchronous replanning while running on different machines. In addition, S IPE –2 can use GisterCL’s evidential reasoning capabilities to choose parameters for operators, and to choose among operators. Both of these capabilities are present in SRI’s Cypress system. SIPE –2, Gister-CL, and P RS - CL
are component systems of Cypress.
In Cypress, P RS - CL executes plans generated by S IPE –2. When PRS - CL determines replanning
is necessary, a replanning request is sent to S IPE –2 while execution of the remaining branches of the
original plan continues without disruption. The planner returns a new plan which P RS - CL integrates with
its current activities. This two-way communication is supported by S IPE –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 S IPE –2 and both P RS - 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 of dictionaries. 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 S IPE –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.
S IPE –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 specified, 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. S IPE –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 a Verifier
that can be used to verify that operators (in the form of Acts) use predicates and functions as specified
by the dictionaries in use.
S IPE –2 can automatically create a new dictionary when an existing S IPE –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 dictionaries are ordered, and the Verifier searches them in the given order. The following sections describe the
use and creation of dictionaries within S IPE –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 S IPE –2 operators
to Acts) and having it correct conflicts that are found between an Act and the existing dictionaries,
although S IPE –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 in
Emacs). 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
1 There
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 schemas
for 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 (S IPE –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 S IPE –2 Acts. In particular, the options for checking types of arguments and matching singular variables to plural classes
should be selected. (For example, if the variable location.1 is used, and the class Location is not
in the dictionary, the system will then use the class Locations if it exists.) The following Act-Editor
function makes a whole set of customizations for
S IPE –2, including those just mentioned as well as common-parent merging:
[Function]
clg::act-sipe-mode
This function sets several variables to customize the Act-Editor for S IPE –2. Environment slots are
displayed as mousable buttons across the top of the graph pane. Typing with completion is used rather
than 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.
[Function]
clg::full-menu-mode
This function enables several additional commands in the Dictionary menu of the Act-Editor. These
commands allow switching between verification and viewing of dictionaries without leaving the Dictionary menu. Note that act-sipe-mode resets the menus to remove these additional commands.
For those who use only S IPE –2, a call to clg:::act-sipe-mode can be included in initialization files or files that load a domain.
2 While
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 predicates with completion is desired, the default option of common-parent merging is best. Common-parent merging also makes
dictionaries 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 S IPE –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 S IPE –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 the Verify command 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 S IPE –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 automatically load their own dictionaries. This is done interactively with the Dictionary command in the Profile
menu. This command brings up a menu with several options for manipulating the dictionaries on the
current graph.
The function add-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 S IPE –2 drawing, or an Act, or has no spaces, or is the default
94
graph (sipe.graph in S IPE –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
Dictionary command (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
(unless load? is NIL). Filename can also be a list of filenames. If replace? is T, any dictionaries already there are first removed. Unless the current graph is empty, contains Acts, contains
S IPE –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 the S IPE –2 sort hierarchy for objects and ACT dictionaries for predicates. If
NIL, completion does not use ACT dictionaries. This variable is set to T when
add-sipe-dictionary declares a dictionary.
The following variables allow declaration of a global dictionary for graphs with no declared dictionary. 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 command
in the Profile menu to call add-sipe-dictionary on the value when invoked. It also causes the
Reset command to reset the following variable when *sipe-dictionary* is on its list.
clg:*global-dictionaries*
[Variable]
A value of nil is the default, which implies that graphs specify their dictionaries. This variable can be
set 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 domain
are loaded.
9.4 Completion
When querying the user for input about the domain, S IPE –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 S IPE –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, S IPE –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 arguments 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,
S IPE –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
S IPE –2 can provide completion of individual names for most planning structures without a dictionary, 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 instances. 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, S IPE –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 the Completion command in the Profile menu.
*select-with-completion*
[Variable]
S IPE –2 and the Act-Editor use typing with completion instead of menus when the number of choices is
greater than the value of this variable. The default is 30. A value of 0 causes these systems to always
use 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 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.
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 listening 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 S IPE –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 term stuck state refers 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 S IPE –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
S IPE –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 S IPE –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 S IPE –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.
1 If any S IPE –2
functions are called from the break in the Lisp window, their output will often still go to the CLIM window
and not to the Lisp window where the function is called. To get the output in the Lisp window, *sipe-output* must be
bound 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.
S IPE –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.
S IPE –2 makes it easy to get pointers to internal structures for debugging purposes. On Symbolics
machines, most text printed by S IPE –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:
[Function]
output-to-emacs
This function redirects the system’s standard output to whatever window was used to launch the Lisp
job (usually Emacs or an xterm).
[Function]
output-to-GUI
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 given
in the keyword types. 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 (after
NODE).
establishers predicate node plan &key . . .
[Function]
This function returns a list of every node in the plan (after NODE) that establishes the given predicate
in its effects.
100
collect-footprint node &key . . .
[Function]
This function collects information about producers and consumers of conditions in the plan. The results
are in *footprint*. The comments in footprint.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.
Highlighting all the nodes mentioning a certain object may also be helpful. Using the Abstract command
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 S IPE –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 function expand-node which applies operators to nodes for the
operator (this can be done by selecting Set Options in the interactive search menu). When the correct
operator application is reached, low-level trace flags can be turned on before resuming execution, or the
function matchcond 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 function possible-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. The List Nodes command 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 S IPE –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 of NIL, 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 customizing 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*
If T, causes S IPE –2 to print timing information when doing deductions.
[Variable]
*time-critics*
If T, causes S IPE –2 to print timing information when applying plan critics.
[Variable]
*time-pc*
If T, causes S IPE –2 to print timing information when matching an operator precondition.
[Variable]
*time-each-level*
If T, causes S IPE –2 to print timing information after expanding each planning level.
[Variable]
*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 not NIL, not T, and not a number, then S IPE –2 prints timing information twice
for each precondition that is matched. The first match will use S IPE –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 deductions are slow, Chapter 17 provides important suggestions, such as using universal variables. A paper 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 conjuncts 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 the instantiate 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. S IPE –2can also backtrack on these forced instantiations if desired.
Declaring domain functions to be no-range-functions, as described in Chapter 12, can speed
up computations involving numerical variables whose constraints apply functions to uninstantiated variables. 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 instantiations 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 S IPE –2. In large domains, the top-level
file generally just contains S IPE –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.
[Variable]
*domain-problem-file*
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 defined after 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 graphically 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 S IPE –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
S IPE –2 operators over the full range of possible constraints on variables.
The following variable should always be set to T 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 is T (default is NIL), 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 the Input command in the Domain menu. The following functions can be called programmatically or from the lisp listener to load input files. On Symbolics
computers, the common-lisp load function can be used to load any input file, but in other Lisps, one
of the following functions must be used.
[Function]
lfile
Prompts the user for a filename and loads the given file using load-and-update.
load-new-file filename
[Function]
Loads the given file, but only if it has not already been loaded since S IPE –2 was reset. It also notes
the file as loaded by S IPE –2. For SIPE –2 to notice that a file is loaded, it must be loaded by lfile,
load-new-file,load-and-update, or the Input command.
load-and-update filename
[Function]
Always loads the given file and notes it as loaded by S IPE –2.
eval-load filename
[Function]
This is the recommended function for loading S IPE –2 input files from a top-level input file. It is similar
to the Common Lisp load function, but some Common Lisp implementations switch the input stream
from the file to the terminal when expressions read from the input stream are evaluated. This function
loads 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 S IPE –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 blocks are blocks that start with a keyword and end with the expression end keyword. Examples of keywords that start definition blocks include: class object operator state-rule
causal-rule. In a S IPE –2 input file, any Lisp expression may be included anywhere except within
a definition block. Such expressions are evaluated during loading.
In S IPE –2’s language, colons (:) and semicolons (;) are always optional. Use them to make a file
more readable. We suggest putting colons after each 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 a sipe-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 its goals slot, the parser will not
complain, but the planner will achieve the first goal only.
106
Operator: Puton1
Arguments: block1, object1 Is Not block1;
Purpose: (On block1 object1);
Properties: Authoring-System = SIPE-2, Class = Operator;
Comment: “Great operator!!”;
Plot:
Parallel
Comment: “Split of champagne”;
Branch 1: Goals: (Clear object1);
Branch 2: Goals: (Clear block1); Comment: “Rad goal”;
End Parallel
Comment: “Tasty Join node”;
Process
Action: 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 S IPE –2 handle these
slots, except that ACT does not currently support properties 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 S IPE –2 syntax.
The plan-printing functions print properties and comment slots on all nodes when the full node
is being printed. The drawing functions draw the properties and comment 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*
If this variable is T (the default), comments are copied from operator plots to the plan.
[Variable]
*copy-comment-down*
[Variable]
If this variable is T (the default), comments are copied down to future plan levels. This controls
copying 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 this
variable is T (the default is NIL), comments in the plan node being expanded are copied down to the
purpose-node. This option will refuse to overwrite a comment already on the purpose-node (copied
from the operator).
For properties, it has proven useful to have different behaviors for different properties. For the
following variables, the values can be T, NIL, or a list where the car is T 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 is T (the default), properties are copied from operator plots to the plan. Value can be T,
NIL, or a list.
*copy-properties-down*
[Variable]
If this variable is T (the default), properties are copied down to future plan levels. This controls
copying when the plan node is copied down without being expanded. Value can be T, 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 this
variable is T (the default is NIL), properties in the plan node being expanded are copied down to the
purpose-node. Value can be T, NIL, or a list. This option will append new properties to properties
already on the purpose-node, but refuse to overwrite a a specific property already on the purpose-node
(copied from the operator).
S IPE –2 sometimes provides information on properties slots. In particular, the replanner sometimes records its actions there, and the execution monitor records the type of node before execution. The
following variable can be set to T to provide data about operator applications:
*save-opr-arg-bindings*
[Variable]
If value is T (default is NIL), the planner saves bindings of each operator’s arguments on the
properties slot of the node which the operator expanded.
108
11.3 Defining Primitive Actions
S IPE –2 considers any process 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 P RS - 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 is nil. The vale can be a list of predicate names, in which case every goal with one
of 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 specifying different predicates as primitives). Thus, S IPE –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:
[Function]
define.domain
This function starts the parser for reading the sort hierarchy, operator definitions, and world predicates.
The parser controls input until it sees the symbol stop at the top level (i.e., not within a definition).
There may be any number of define.domain commands, except that each file must have a beginning
define.domain and a corresponding stop. Any input so surrounded may be in a separate file, but
the description of the sort hierarchy must be surrounded by a define.domain and a corresponding
stop, and must be loaded first.
[Function]
define.problem
This function starts the parser for reading problem definitions. The parser controls input until it
sees the symbol stop at the top level. Any number of define.problem commands can be
used. 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 interactively from a Lisp listener and the input typed to the system, provided that no colons or semicolons are
used (S IPE –2’s readtable is not used).
The syntax for top-level declarations and definitions is
domain
::= (define.domain) domain.def stop
problem.def
domain.def
::= (define.problem) problem stop
::= 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 the Expr class, or a numerical instance (i.e., a number or list of numbers)
which is represented as an instance of the Numerical class. An Expr matches only another Expr whose
s-expression is equal. By storing s-expression and numerical literals in the sort hierarchy, S IPE –2
permits variables such as expr.1 and numerical.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 (S IPE –2 will issue a warning).
Normally, a S IPE –2 variable name is a class name followed by integers, or by a “.” and integers (see op-variable-names? below). The variable verbatim-variable-names? can
be set to T to allow other names as described below. This is useful for descriptive names such as
destination-airport class airport instead of airport.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 if
it’s plural) and appending an integer. If the global variable op-variable-names? is T (the
default), 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 class
BLOCKS in the sort hierarchy, operators can speak about arbitrary blocks by saying block1, block7, or
block.12. This generates an indefinite node when the operator is applied. The indefinite node
represents a planning variable with the constraint that it must be a member of the class blocks. Note
that 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 . and
integers), it will be, but if it cannot (either because of no trailing integer, or because the name before
the 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 a sort hierarchy.
The sort hierarchy defines the classes and objects that exist in the domain and is composed of
class and object 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 individuals. 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 should not 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 S IPE –2 to incorporate the advantages of frame-based systems (primarily 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 instantiations 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
Sort
Hierarchy
Static
Predicate
Instances
Dynamic
Predicate
Instances
@I@
@,
,,
Rules
User
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 S IPE –2 sort hierarchy
into an agent. This should allow S IPE –2 to access other databases and allow other agents to access any
S IPE –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. S IPE –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 S IPE –2 hierarchy subsystem.
To further facilitate access 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, S IPE –2 can now be run with any frame representation system for which
GFP has been implemented (e.g., USC/ISI’s Loom, SRI’s S IPE –2 sort hierarchy, CMU’s Theo, Stanford’s Ontolingua). A similar agent could easily be provide for OKBC. However, there is a substantial
cost in efficiency, so the distributed S IPE –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 S IPE –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 S IPE –2 sort hierarchy, without knowledge of the S IPE –2 syntax.
It will save the hierarchy to a file that can be loaded into S IPE –2. Instructions for loading and using
the GKB-Editor are given in Chapter 8. The GKB-Editor is invoked through the Modify 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]
S IPE –2 interns class and object names and makes them point to their corresponding internal structure. Thus, one can inspect the value of these names to see their internal representations. Instance
and inst are synonyms for object. Class nodes can have the following slots: subclasses,
instances, parent (or parent-class), comment, and properties. Object nodes may
have only the latter three slots. The values of properties should be an a-list, while the value of
comment can be any s-expression.
sort-hierarchy
[Variable]
S IPE –2 generates a root node which is pointed to by the global variable sort-hierarchy. Any
input class that has no parent becomes a subclass of the root.
sipe-classes
[Variable]
This class is a subclass of sort-hierarchy, and has as descendants all classes used by the system.
In particular, all numerical classes and instances are descendants of sipe-classes. To display the
sort hierarchy without seeing theses classes and instances, the unlink-classes function can be
used.
unlink-classes parent-class subclass
[Function]
This function removes the link between two classes. This is useful for displaying the sort hierarchy
without seeing the system classes and instances. This is done by evaluating (unlink-classes
sort-hierarchy sipe-classes. This link can be permanently deleted as it is used only when
displaying the sort hierarchy from its root.
113
link-classes parent-class subclass
This function restores the link removed by calling unlink-classes.
[Function]
Before the release of the GKB-Editor, sort hierarchies were either input using S IPE –2 syntax, or
through a list structure that must be converted to S IPE –2 syntax with the convert 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).
S IPE –2 input for part of a sort hierarchy describing food is as follows:
CLASS: VEGETABLE
PARENT-CLASS: FOOD
SUBCLASSES: CHOKES, CORN, SPROUTS, MUSHROOMS
END CLASS
CLASS: CHOKES
PARENT-CLASS: VEGETABLE
PROPERTIES:
STEAM-TIME = 45;
INSTANCES: CHOKEA, CHOKEB
END CLASS
OBJECT: CHOKEA
PARENT-CLASS: CHOKES
PROPERTIES:
COLOR = GREEN, SIZE = 5;
END OBJECT
[Function]
convert
This function converts a simple list structure of classes and objects into a S IPE –2 input file. It prompts
for an input filename of list structures and writes that file with a .sipe extension that is suitable for loading
directly into S IPE –2. The file will correctly define all objects and classes in the input list structure. Here
is an example of an expected input list structure with some values specified for the foo property:
(class plant
(foo baz)
(class cellar
(object m-cellar (foo bar))
(object l-cellar))
(class beer-tank
(object bt-m1)
(object bt-m3)))
1 For
creating files of SIPE-2 syntax, it is recommended that the user use the copying capabilities of an editor to copy a
class template and fill in the blanks correctly.
114
[Function]
save-hierarchy
This function writes the current sort hierarchy out to a file on disk as a simple list structure of classes
and objects suitable for input to the function convert.
12.3 Inputting Initial World Predicates
S IPE –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 predicates 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 S IPE –2 uses the closed-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 with unknown 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 is unknown. Thus, an open predicate instance with unknown 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 openpredicate 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 if in 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 function init.deduce. Remember,
init.deduce must be called before the problems are defined. (This is described in more detail in
Chapter 13.)
[Function]
init.deduce
This function applies deductive rules to the initial world. It must be called after the predicates and deductive 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
domain.def
pred-decls
::= [[ static-decl j open-decl j closed-decl j function-decl ]]
static-decl
open-decl
::= static-predicates ( pred-name )
::= open-predicates [( pred-name ) j t]
closed-decl
function-decl
::= closed-predicates ( pred-name )
::= no-range-functions ( fun-name )
predicates
::= [[ predicates predlist end predicates j
predlist
pred
additions predlist end additionsj
initial-additions predlist end initial-additions ]]
::= pred ff,g predg f;g
::= f-g(pred-name fpred-argg ) j (not (pred-name fpred-argg))
The meaning of the keywords relating to predicates is documented below:
[Keyword]
predicates
This keyword indicates the predicates following it will be placed in a newly created world.
[Keyword]
additions
This keyword indicates the predicates following it will be added to one specific existing world. This
is useful for doing “what-if” analyses. The system queries the user about which world should have the
additions.
116
[Keyword]
initial-additions
This keyword is used to change the common world for all problems that will be defined later. This
permits multiple files to be used in defining an initial world. Additions is meant for changing one
particular existing world that already has deductions done. Initial-Additions is used for initial
world predicates that are present in all problems and that have not yet had deductions done.
[Keyword]
static-predicates
This keyword is followed by a list of predicate names and declares them as static. It should be inserted
within the scope of a define.domain before any predicates are defined. The following example
declares adjacent and connect to be static predicates:
STATIC-PREDICATES: (CONNECT ADJACENT)
[Keyword]
open-predicates
This keyword is followed by t or a list of predicate names and declares them as open predicates. It
should be inserted within the scope of a define.domain before any predicates are defined. A value
of t makes all predicates default to be open, and closed predicates must then be declared as exceptions.
[Keyword]
closed-predicates
This keyword is followed by a list of predicate names and declares them as closed predicates. It should
be inserted within the scope of a define.domain before any predicates are defined. It is not needed
unless an open-predicates t declaration has been made.
[Keyword]
no-range-functions
This keyword is followed by a list of function names and declares that they will not be computed until
their arguments are instantiated. In one domain with around 100 possible instantiations 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.
117
Chapter 13
Operators
The Act-Editor is now the recommended method for encoding operators in S IPE –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 S IPE –2: operator, state-rule, causal-rule and
init-operator. If an operator is defined as both-operator then it becomes both an initoperator and a state-rule. An operator has a plot that describes how to expand a goal 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 S IPE –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, variable refers 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 named puton1. The id, type, properties,
and comment slots are present on every internal structure and are filled in automatically by the system.
118
Operator: Puton1
Arguments: block1, object1 Is Not block1;
Purpose: (On block1 object1);
Plot:
Parallel
Branch 1: Goals: (Clear object1);
Branch 2: Goals: (Clear block1);
End Parallel
Process
Arguments: block1,object1;
Resources: block1;
Effects: (On block1 object1);
Figure 13.1: SIPE-2 Input for Puton1 Block-World Operator
Causal-Rule: Not-On
Arguments: object1,object2,object3;
Trigger: (On object1 object2);
Precondition: (On object1 object3);
Effects: :(On object1 object3);
End Causal-Rule
State-Rule: Deduce-clear
Arguments: 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, and trigger 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 value
is 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 of arguments. It implements the notion of reusable
resource as the system assures that any resource will not be used by another action in parallel. Resources
can 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 of arguments. These variables are instantiated by the
system 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 for
encoding 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 planner
wants to be true but will not try to make true. If you want the planner to make them true, put them as
goals in the plot of the operator. This provides added flexibility, since it is common that one wants to
apply an operator if a certain situation exists, but does not want to achieve that situation if it does not
exist. Satisfying a precondition (for any type of operator) generally constrains the variables that are
arguments of the precondtion. If X is a variable in P, a precondition, only instantiations of X for which
P is true will be considered hereafter (i.e., x j P(x)). During matching of such a precondition, the system
generates constraints enabling the variable to match all and only those objects for which the precondition
is 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 conditions
and preconditions are the antecedents of deductions but are matched under different circumstances (see
Chapter 17).
purpose operator
[Function]
This slot is a list of predicates, and is present only on regular operators. It describes what the operator is
trying to accomplish and is used to determine to which goals this operator is applicable. It is also used
to 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 a
deduction.
trigger operator
[Function]
This slot is a predicate, and is present only on deductive rules. It triggers the application of the operator
when 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 constraint
consists of one of the thirteen Allen constraints and the two nodes to which this constraint applies. The
syntax refers to the nodes by the names of their goals or action, and also permits numerical intervals as
part 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 the
arguments of the operator, but a warning message is printed out in case one of them is misspelled. Plots
are described in detail in Chapter 14.
121
The syntax for operators is
operator.def
real-op
rule
causal-rule
::= [real-op j rule j causal-rule]
::= operator op-name f;g args [[ resources j instantiate j purpose j
precondition j t-constr-slot j prop-com ]] fplotg end operator
::= rule-type op-name f;g args [[ trigger j effects j condition j
prop-com ]] end rule-type
::= causal-rule op-name f;g args
[[ trigger j effects j condition j precondition j prop-com ]]
rule-type
end causal-rule
::= [state-rule j init-operator j init.operator j both.operator]
trigger
::= trigger pred f;g
purpose
precondition
::= purpose pred f;g
::= [precondition j preconditions] predlist
condition
effects
::= condition predlist
::= effects predlist
t-constr-slot
::= constraints: ftconstraintg f;g
predlist
pred
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
point
::= later j later-eq j earlier j earlier-eq j equals
::= start j end
node
node-name
::= ( node-name f . integerg)
::= op-name j pred-name
prop-com
::= [[ properties j comment ]]
properties
prop.dec
::= properties prop.dec f, prop.decg f;g
::= prop-name = sexp
comment
::= comment sexp
122
13.2 Operator Arguments and Constraints
The programmer can define local variables in operators and problems using the arguments,
resources, or instantiate slots or implicitly by reference to it in the plot. Recommended style
for operators is to define arguments using the arguments slot; if the user defines a named argument
implicitly or within a plot, S IPE –2 prints a warning. The warning helps detect misspelled argument
names. Because constraints do not vary with time, S IPE –2 generates the same internal representation
whether constraints are defined in the arguments of the operator or in the plot.
Variables in operators are named, constrained, and bound through the arguments slot of the operator which determines how the operator is matched to a node. Individual plot nodes can have an
arguments slot as well as a resources 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
the arguments slot of the operator to the arguments slot of the node. For process nodes, this is
the obvious algorithm. For a goal 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 its goals 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 its purpose predicate. If S IPE –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 is NIL, as
not following this convention can lead to confusing behavior.
The permitted variable names and literals are described in Section 11.5. Constraints can be appended to variable names in the arguments and resources slots. The constraints permitted are
documented in the BNF below. Here are more readable examples:
CLASS EXISTENTIAL
CLASS UNIVERSAL
CLASS <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 all With constructs, 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 the With construct is evaluated. Note that equal to and not 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 operator will be (instead of being interpreted as a value). The first With construct (WITH attribute
value) is like the equal 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.def f, arg.defg f;g
resources
sresources
::= resources arg.def f, arg.defg f;g
::= [sresources j sharedresources] arg.def f, arg.defg f;g
instantiate
::= instantiate arg.def f, arg.defg f;g
pred-arg
arg.def
::= [literal-arg j arg-name]
::= [literal-arg j named-arg]
literal-arg
::= [object-name j expr-form j numerical j function j range]
expr-form
numerical
::= (expr sexp)
::= number j (number)
function
range
::= (symbol [numerical j symbol])
::= [numerical f,g numerical]
named-arg
constraint
::= arg-name fconstraintg
::= class-con j quant-con j is-con j with-con j with-eq j same-con
class-con
::= [of type j class] class-name
124
quant-con
is-con
::= class [existential j universal]
::= is [is-not j is-current j numerical j expr-form j function
is-not
j range j object-name]
::= not [[of type class-name] j object-name j (object-name) j arg-name]
is-current
with-eq
::= [current j previous] value of arg-name
::= with prop-name fequal tog [numerical j arg-name j sexp]
with-con
::= with prop-name [greater j =greater j less j =less] than
merical j arg-name ]
::= same fasg arg-name
same-con
[nu-
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 a vardes (for variable description). A
vardes is a list of at least three elements that describes to the system how to create an actual S IPE –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 the constraint case
or is the structure representing the instance (object) or expr in the other cases. For example, evaluating
(arguments puton1) in the blocks world (the puton1 operator 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 are varptrs (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 type indef
(for indefinite) represents a planning variable, an instance is an object from the sort hierarchy, and
an expr is an Expr. An indef structure stores constraints that accumulate during planning, indexing
them by context. The choice-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 their properties 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 describes 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, variable refers 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 documented in Appendix F.3. The slots the user might specify for a Group 1 node in an operator
are arguments, resources, effects, delay, delay-execute, external-condition,
protect-until, duration, start-time, and stop-time. In addition, goal nodes would
specify a goals slot, and choiceprocess and process nodes an action slot. There is also
a loop facility — a process node whose action is generate-goals must have a pattern 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 and endcond nodes are similar to split and join 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 the endcond
is reached. The condpattern 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 atom copy which directs the system
to copy the previous node instead of expanding it. This allows the programmer to control the abstraction
level at which S IPE –2 expands a goal. The programmer needs to use the preconditions and constraints
to eventually terminate the match to the copying operator.
branch number
condpattern number
[Keyword]
[Keyword]
These are used to declare the beginning of a new branch after either a split or cond node. Both of these
are followed by a number that SIPE –2 ignores. The number could be anything; there is no need to
number the branches in any particular order.
[Keyword]
copy
Copy directs the system to copy the previous node instead of expanding it. Copy should be the only
step in the plot since S IPE –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 by problem: name and end problem instead of plot and end 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 described in Section 13.2. However, this is generally only used in problems, as operators specify their
constraints in the arguments 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-stack
Parallel:
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 its id 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 the
list worlds. The plot form is a list structure version of the S IPE –2 syntax, with no punctuation, the
labels after end omitted, and a list around each predicate and around each parallel and cond group.
There must be an end for each parallel and cond group and the end of the problem.
Here are two example calls to make-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
effects node
[Keyword]
[Function]
This slot is a condition (a list of predicates) that represents the context-independent effects the action
has on the world. Context-dependent effects are then deduced from these given effects by the deductive
rules.
delay boolean
delay-execute boolean
delayp node
[Keyword]
[Keyword]
[Function]
This slot is T, NIL (the default), or delay-execute. It becomes T if the user specifies the symbol
delay as a slot name with no punctuation, as in Figure 14.1. The function delayp 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 be
delayed until the robot is executing the plan it has produced for other goals). Alternatively, the token
Delay-execute can be used to indicate that planning of a node should be delayed until execution of
that node. This provides a way to intermingle planning and execution in a given domain.
external-condition boolean
external-condition node
[Keyword]
[Function]
This slot is a boolean which becomes T if the user simply specifies the symbol
external-condition as a slot name with no punctuation. It applies only to goal nodes and
indicates that the goal is not to be achieved by planning actions, but rather will be achieved by a
possibly parallel action and phantomized by an ordering link. This is useful for coordinating actions on
parallel branches and is described in Chapter 16.
protect-until condition
purpose node
[Keyword]
[Function]
This slot provides specification of the plan rationale and helps the execution monitor discover problems
during execution. The function purpose accesses the slot input as protect-until. S IPE –2 ensures that
the main effect of the action remains true until the condition holds. The condition may be either a
predicate list or the atom purpose. The latter indicates that the main effect must be true until its
containing operator’s purpose comes true. If the containing operator was applied at the top level of the
problem, then the main effects must be true at the end of the plan.
130
start-time numerical
stop-time numerical
duration numerical
[Keyword]
[Keyword]
[Keyword]
These slots take one planning variable as their value. The variable should be an argument of the current
operator with appropriate constraints to be interpreted as a time. In particular, it must be a numerical
variable. S IPE –2 then translates these slots into effects of the same plot node, as described in Section
18.6.
action action-names
[Keyword]
action node
[Function]
This slot must be a single action name on a process node and a list of action names on a
choiceprocess node. The system adds information to this slot when the node is expanded. This
information 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 problem
in Figure 14.2 uses both long and short syntax. In long syntax, a goal node (like all nodes) normally
must start with its type, goal, and must also have a goals attribute. However, the short syntax permits
the type of the node to be omitted when the node starts with a slot name of either goal or goals1
followed by a predicate. The arguments default to the arguments of the first predicate in the goals slot.
In describing problems, it may be useful to use the long syntax which permits specification of constraints
since the arguments can be given explicitly. In long syntax, the arguments and resources slots
must come before the goals slot (which must be given).
14.3 Generating Parallel Goals
A process node whose action is generate-goals is 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,
S IPE –2 generates a split-join with N goals between them. Any delay, 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, and arguments.
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.
1 In
this case only, goal and goals are interchangeable.
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 does
not recognize when new goals should be added, or old ones deleted. In addition, the operator fails when the pattern has no
matches (either during planning or replanning).
2 In
131
Operator: Cleartop-generate
Arguments: object1, object2 is not object1, block1;
Purpose: (clear object1);
Plot:
Process
Action: generate-goals
Goals: (on block1 object2)
Pattern: (on block1 object1)
Arguments: object2
Goal: (clear object1);
Figure 14.3: Cleartop Operator Using Generate-Goals
The goals and arguments slots are used by the algorithm that constructs each goal to be inserted.3 The goals 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, the arguments slot of the generategoals 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 generategoals action. This means any variables used in the arguments 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
3 The
slot must be goals not goal 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 appropriate. The system creates some plan structures to support this, which you may notice in plan drawings.
A Generate node 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 for each 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.step
::= plot [copy j plot.step] end plot
::= [goal.step j shortgoal.step j proc.step j cproc.step j par.step j parexp.step j
cond.step j choice.step ]
goal.step
::= fgoal goal.modg goals
shortgoal.step ::= [goal j goals] pred f;g fgoal.modg
goal.mod
::= [[ delay j external-condition j resources j sresources j args j protect j
effects j time j prop-com ]]
proc.step
::= process action op-name f;g fproc.modg
parexp.step
cproc.step
::= process action parexp f;g fparexp.modg
::= choiceprocess action op-name f, 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
proc.mod
goals+ j pattern+ j prop-com ]]
::= [[ delay j delay-execute j resources j sresources j args j protect j effects j
time j prop-com ]]
par.step
::= parallel fprop-comg branch end parallel fprop-comg
branch
cond.step
::= branch number plot
::= cond fprop-comg condbranch end cond fprop-comg
condbranch
::= condpattern number pred f;g plot
effects
pattern
goals
::= pattern pred f;g
::= goals pred f;g
protect
time
::= [protect-until j purpose] [purpose j predlist]
::= [[ [start-time j stop-time j duration] numerical ]]
134
Chapter 15
Customizing the Planner
This chapter describes the Planning and Efficiency commands from the Profile menu and explains contexts. The Planning command gives access to the most important variables for controlling planning
functionality, while the Efficiency command 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 S IPE –2 customizations followed by a series of s-expressions to load files for the sort hierarchy, initial world, and operators.
The Planning and Efficiency commands set global variables. To avoid doing this interactively each time
the domain is loaded, set the global variables appropriately in the S IPE –2 input. The variable names to
use in the input file can be found in this manual, in the file globals-customize.lisp, or by editing 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. The
function should take one argument, a planhead node and a second optional argument which is a
context. The function is called before the problem is copied to a partial plan, and before a plan object
is 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
[Variable]
numerical-enabled?
Enable numerical reasoning capabilities.
Disabling the above capability when it is not needed can improve performance.
new-data-each-level
Allow user to enter new data at each planning level.
136
[Variable]
If T, the system stops at the beginning of each planning level and asks the user for new information about
the state of the world. Algorithms used in the replanner are then invoked to fix the plan in response to
any unexpected events. This facilitates planning in a world that is changing during planning. The default
is 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 instantiated, then this should be T. If deduction is used extensively, planning can be considerably less efficient
when deductions must be redone. This has been NIL in all applications of S IPE –2 to date, and NIL is
the 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 goals
cannot be prevented by searching all possible plans for the Army. Thus, these goals are independent of
the Army plan.
For completeness, if a goal G fails, backtracking still has to try all possibilities for goals in parallel
with G since they may influence later expansions of G. Declaring a goal independent tells the system that
the parallel goals cannot make G succeed. Thus the search can skip to a backtracking point that preceeds
G (skipping backtracking points for parallel actions). Solutions may be missed if the independent goals
do depend on parallel actions.
*independent-goals*
[Variable]
The value is T, NIL (the default), or a list of predicate names. The search will skip backtracking
choices based on the assumption that parallel actions will not affect goals with one of the given
predicate names (or any predicate name, if the value is T).
15.1.2
Ordering links
plink-enabled?
Enable links between parallel branches.
Disabling the above capability when it is not needed can improve performance.
[Variable]
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 starttime and duration slots. This has been NIL in all applications of S IPE –2 to date; otherwise, an enormous
number of links are added and the plan becomes unreadable. The system should distinguish between
timing links as above, and causal links such as currently added by the critics. By keeping them separately, 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 planner
flashes a plink between node1 and node2 only when this function returns non-nil.
15.1.3
User Interaction
automated-planning-display
Display option after automatic plan generation (:use-menu allows naming).
[Variable]
The value must be one of (:draw :print :use-menu :neither).
automated-replanning-display
Display option after automatic replanning (:use-menu allows naming).
[Variable]
The value must be one of (:draw :print :use-menu :neither).
[Variable]
interactflg
User chooses operator to apply.
The value is a boolean, if T, the user will be asked to choose when there is more than one operator to
apply.
automatic-allocation
Automatically instantiate forced instantiations without asking user.
[Variable]
For variables that are listed on instantiate slots of operators, this variable directs the system to
instantiate them either automatically or interactively.
*interactive-res-conflict*
User chooses resource orderings, and how to display them.
[Variable]
If NIL (the default), the planner automatically resolves resource conflicts. If non-nil, the system displays
a menu for each resource conflict and lets the user choose the ordering. The value of this variable
determines how the conflict is presented to the user before the menu is created. If :draw, the conflict
is 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 and
printed.
[Variable]
flash-node-on-expansion
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 expanded. This only works if the plan with the nodes is currently drawn on the screen. The default is
T.
138
15.1.4
Critics
[Variable]
*fail-on-resource-conflict*
Prevent resource conflicts with hard constraints.
S IPE –2 provides two different notions of reusable resource. When resource conflicts occur, the system
orders actions to prevent them. For example, when trying to drive two nails, the planner would do
one before the other if only one hammer were available. However, in other domains, such as parallel
actions being scheduled for different production lines, a resource conflict indicates an invalid plan (the
lines must be run in parallel), so S IPE –2 provides the additional option of considering resource conflicts
as unacceptable [9]. If this variable is T, the system posts not-same constraints to prevent resource
conflicts from occurring and never invokes the resource critic (since it is now superfluous).
add-protect-untils
Automatically protect each action until end of plot.
[Variable]
If T (the default), each action/goal in the plot of an operator is protected until the last node in the
plot, unless a specific protect-until construct is used to specify a different protection interval. If
NIL, no protection intervals are entered into the plan except where the protect-until construct is
explicitly used.
[Variable]
phantomize-choiceprocess
Make phantoms out of choiceprocess nodes.
If T (the default), choiceprocess nodes are considered more like goal nodes and are changed to
phantoms if their main effects are already true. Otherwise, choiceprocess nodes are considered
more like process nodes and one of the actions specified is applied.
phantomize-by-constraints-without-ordering
Instantiate to phantomize, T/NIL/ONE with exception list.
[Variable]
This variable applies in the case when phantomization can happen without ordering any actions. If T
(the default), the system instantiates or constrains variables in order to phantomize goals. This may
cause the system to miss solutions by not considering actions to achieve these goals, since it will not
backtrack over this choice. If NIL, 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 this
variable can also be a list as well as a symbol. For a list value, the car of the list is one of T NIL ONE
and the cdr of the list is a list of predicate and action names which are exceptions to the setting in the
car of the list. For example, if the value is given as (t connect), all goals have constraints added
for phantomization except a goal to achieve any predicate whose name is connect. An exception to a
value of ONE is to add no constraints.
phantomize-by-constraints-with-ordering
Instantiate to phantomize with ordering link (T NIL or ONE).
[Variable]
This variable applies in the case when phantomization can happen only by ordering actions. The system
checks for possible instantiations that allow it to phantomize parallel goals by ordering them before
or 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 these
choices. If this variable is NIL, the system never posts constraints. If T, the ordering link and constraints
are added if the only constraints that need to be added are notpred or not-same constraints. This
is a conservative approach as pred, same, and instan constraints are not added. Effectively, this
means that some plan node phantomizes the goal exactly and the only constraints added are to prevent
intervening actions from undoing the goal. The default is to set this variable to ONE, the most permissive
choice. In this case, S IPE –2 does what it did in the T case, but in addition posts instan and same
constraints, but only when there is only one possible instantiation that lets an ordering phantomize the
goal.
*parallel-phantomize-by-addition*
Phantomize level goals by ordering links to produce/consume effects.
[Variable]
If T (the default), the planner searchs for a set of nodes with produce and consume effects that
together accumulate a certain quantity of some resource to make a level goal true. This phantomization will require an ordering link for each member of the set. If the value is :one-link, the planner
searches only for a single node that achieves a level goal by itself, thus adding one, and only one,
ordering link. Note that one ordering link may place several produce/consume actions before the phantom. If the value is NIL, the planner only phantomizes a level goal by matching another level
predicate.
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 to NIL 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 should
take two arguments, a planhead node and a plan object. The search fails if NIL is returned by this
function.
*domain-critic-frequency*
Frequency in levels for checking *domain-critic* (1 is default, 0 disables)
[Variable]
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 Failuninstaned is a boolean. Funct is a function with Arity number of arguments that is called when the
planner is trying to ascertain whether a predicate with this name and arity is true. If Funct returns
the symbol FAIL, the planner assumes the predicate did not match. For any other value, the planner
assumes 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 S IPE –2 knowledge, 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 function add-constraint).
There is an example procedural attachment in doc/procedural-attachment-example.lisp.
This file includes an attached function that posts constraints on variables.
15.3 Efficiency Profile
The Efficiency command 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 the Efficiency command is to set the frequency of application (in planning
levels) of various critics. Critics are always checked before a final plan is accepted; 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*
Check all future preconditions after every ordering/operator.
[Variable]
Allowable values are t nil :replace :accept :reject. If non-nil,the system checks the
truth of all following preconditions each time an ordering is added or an operator is applied. By checking future preconditions, the system can avoid parts of the search space that do not have a solution
since it recognizes a problem immediately instead of waiting for critics to be applied. If precondition
checking is fast, this is a win. However, in large domains with complex preconditions this can be too
computationally expensive, so this variable is often set to NIL 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 preconditions. If :replace, remove wedge for precondition and replace with root of wedge. Use :replace
with caution – it is in beta-test and backtracking may not work with it. In addition, it is incompatible
with multiple solutions as replacing wedge will destroy other solutions. If T, a menu will be displayed
for each false precondition to let the user choose between :replace :accept :reject.
*check-precond-conflicts*
Check precondition conflicts with parallel actions.
[Variable]
This variable informs the CBG critic about how to protect parallel preconditions, thus permitting preconditions to be used in different ways in different domains. If :instantaneous (the default), the
system checks conflicts with a precondition only at the instant of the precondition. If :purpose, the
system makes sure that there is no conflict with the precondition anywhere in the interval from the precondition to its purpose. If NIL, preconditions are not checked for parallel conflicts. In large domains
with complex preconditions and many parallel actions, any non-nil value can be computationally expensive. Most domains intend preconditions to be true instantaneously, and that is the default semantics of
S IPE –2.
The setting of this variable is determined by how preconditions are used in the domain. This variable
can be safely set to NIL if all predicates affected by parallel actions and placed in the plots of operators
as goals (to become phantoms), instead of in the preconditions. This is generally what is desired, in
any case. The phantoms will be protected by the critics and a parallel action might phantomize the
predicate. If *check-precond-conflicts* is NIL in a domain where precondition conflicts
exist, plans may be produced in which certain execution orders of unordered actions may result in a
precondition-test failure in the executor for some precondition. Goals and phantoms are guaranteed true
for all execution orders.
*cbg-frequency*
Frequency in levels for checking parallel interactions (1 is default, 0 disables).
[Variable]
*resource-frequency*
Frequency in levels for checking resource conflicts (1 is default, 0 disables).
[Variable]
142
remove-redundant-actions-frequency
Frequency for precondition-check/wedge-removal (1 is default, 0 disables).
[Variable]
*temporal-frequency*
[Variable]
Frequency in levels for checking temporal critic (1 is default, 0 disables). The use of the temporal critic
is also controlled by other variables as described in Section 18.6.2. Thus, the temporal critic may be
disabled even if the frequency is non-zero.
There is always a tradeoff in how often to apply plan critics. These variables allow control of how
many planning levels pass before each of the given critics is applied. The default is 1, i.e., they are
applied at the end of each planning level. These values can be set to an integer to apply critics less
frequently or not at all. Critics are disabled entirely if the frequency is set to 0, and are applied to the
final plan only if the frequency is set to a number higher than the depth limit.
*res-res-conflicts-only*
Only check resource-resource conflicts, not resource-argument conflicts.
[Variable]
If T, the resource critic may be speeded up by recognizing resource conflicts only when both conflicting
actions declare the resource. The default is for a resource to conflict with any argument, whether a
resource or not.
[Variable]
recheck-phan-deduce
Recheck phantoms after adding an ordering link.
If T (the default), this variable tells S IPE –2 that it must recheck phantoms and deductions when it copies
a non-expanded node down to the next plan level. In general, this must be done since further planning at
the next level may have invalidated the deductions or the phantomizations. If, in a given domain, further
planning never undoes deductions or phantomizations, the system can be speeded up by setting this to
NIL.
15.4 Plan objects
As of version 5.2, S IPE –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
1 This facilitates tracing as plan objects print in 1 line, e.g.,
PROGRESS>.
143
<AIR-SUPERIORITY-A-V9-13,
179 choices, IN-
Plan object Slot
name
action-network
action-network-name
context
status
problem-name
last-choice
advice
advice-scenario
requestor
properties
comment
Value
name of plan (bound to planhead of action network)
plan node
name of action network (bound to plan node)
context (list of CPPs)
:final, :partial, :in-progress, or :replanning
name of problem (bound to partial plan for task solved)
last CPP created
list of advice in effect
name of last advice scenario selected
name of agent requesting plan (symbol or string)
property list (not used by system)
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 of CPPs, 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*
Value is the plan object of the last plan found by the automatic search.
[Variable]
*current-plans*
[Variable]
Value a list of plan objects for all the plans found by the most recent invocation of the automatic search.
2 For
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, either
reload 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 to
the drawing that is visible.
dcontext
[Variable]
GUI functions set this variable to the name of the context used for the most recent plan drawing. This
name 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 a context is central to S IPE –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.
The List Nodes command 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 of NIL, 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 a choice 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 (alternatively, 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 the desc and
action slots 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 of CPPs, 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. S IPE –2 plan structures are accessed by doing eq
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 backtracking. 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 argument. Also, each plan node has an sjcontext 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 Section 15.4):
original-cpp
Value is the initial dummy CPP that is in all contexts.
[Variable]
original-context
Value is the initial context used for every plan.
[Variable]
146
Chapter 16
Reasoning about Partially Ordered
Actions
Advanced concepts: This chapter explains why S IPE –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 S IPE –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.
S IPE –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 a nonlinear planner. 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 the least-commitment
approach.
147
A planner’s truth 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 S IPE –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, S IPE –2 has heuristic algorithms for avoiding some of
the combinatorics.
16.1 Efficiently Handling Partially Ordered Actions
S IPE –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 on plan critics that check for and correct problems in these plans. These
critics are applied after each planning 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, solvers are applied to modify the plan, possibly adding
ordering constraints to the actions. Solvers in S IPE –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 a nonshuffling 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. S IPE –2 produces a plan with a minimal number of ordering constraints for this problem.
One possible ordering implicit in this plan, and produced by the Regroup command in the Plan menu, is
the one with all the footings, columns, and beams in parallel.
Because of the unacceptability of the nonshuffling restriction, S IPE –2 allows all possible orderings
of unordered actions while maintaining its efficient truth criterion. S IPE –2 permits parallel 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 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
S IPE –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 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. For efficiency, the system keeps
149
parallel-pred-here and parallel-succ-here slots at lower levels when links can be calculated, rather than recomputing links by following the higher-level links stored in the parallel-pred
and parallel-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
as external-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 S IPE –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 to changes between 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.
S IPE –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 (see rededuce-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 producing 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 repeated 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 implemented, 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) and 8x::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 formula. 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-region
Arguments: object1,region1,region2 is not region1;
Trigger: (at object1 region1)
Precondition: (at object1 region2)
Effects: (not (at object1 region2))
State-Rule: at-region
Arguments: 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. Initoperators 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
Uninstantiated variables greatly increase the computational complexity of doing deductions, particularly
if many instantiations exist. Chapter 10 describes forcing instantiations by using the instantiate
slot in an operator definition. This technique can speed up deductions by one or more orders of magnitude if key variables are instantiated. Similarly, declaring functions as no-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 are functional in 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 advantage 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 S IPE –2 application shows the importance of using universal variables. 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 constraint object1 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 the object1 variable has been
further constrained to be a block. It would also do it if the deductive rule specifies object1 class
blocks instead of block1. 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. S IPE –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.
S IPE –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 treating numbers as objects, and by providing numerical variables, numerical constraints, and numerical
predicates. The system automatically computes level predicates from predicates that produce and
consume numerical quantities, and the user can specify goals and preconditions that involve these levels. The system notices when a set of actions that produce a resource together satisfy a level 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 instantiations 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 following two global variables control the reasoning about lists of numbers. They can be set by using the
Numerical command 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 two
numbers. Instead of numbers, the following recognized symbols can be used: (seconds minutes
hours days months years). These correspond to the obvious numbers, except that the
computation of days carrying into months is adjusted for months of 28, 30, and 31 days. The default
value is shown in Figure 18.1. The user can customize the temporal representation simply by setting
this 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 the
list. If NIL, they are added in reverse order. For example, a list of numbers intending to represent
(day month year) would require T for this variable, while a list of numbers intending to
represent (hour minute second) would require NIL.
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, numerical and continuous.
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 consumable 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
post produce and consume 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 S IPE –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 continuous variable.
The actions of moving across the river post produce and consume effects, which are used by the
planner to compute the continuous variable.
Continuous variables introduce complications. They cannot have pred constraints, which guarantee 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 constraining level 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 term numerical variable will 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 continuous
variable at some point in the plan. This permits operators to reason about and place constraints
on 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 the
current 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 number of arguments. If some of these arguments are not instantiated, S IPE –2 computes a range from
the function constraint by calling the function on all the possible instantiations. For efficiency, it
is often desirable to not compute these ranges.
Summary-range — Since computing the above constraints (especially function constraints) can be
expensive, 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 placing a summary-range constraint on the variable. (This cannot be done for continuous variables
because their values vary with time.) These constraints are not posted by users but only by the
system.
The syntax for numerical literals and constraints (from Section 13.2) is
literal-arg
numerical
function
range
constraint
::= class-con j quant-con j is-con j with-con j same-con
is-con
::= [current j previous] value of continuous-arg-name
is-current
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, S IPE –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, S IPE –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 S IPE –2 argument, and it should return either T or a S IPE –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*
Value is the node currently being expanded by the planner.
[Variable]
For doing arithmetic directly on S IPE –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 variables, 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 are n possible instantiations for loc1 and m possible instantiations
for loc2. In some domains, computing this bound for duration1 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. The
default value is (SIPE+ SIPE- SIPEMAX SIPEMIN SIPE* SIPE*-ROUND). Values should
be 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 instantiated
t ;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 (if size 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 that num-or-vp is
called to extract numerical objects from numerical variables, and that T 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 it cv-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 S IPE –2 may ignore these constraints.
1 The eventual cv-node can be determined only when the plot nodes are converted to plan nodes. When applying the
operator, SIPE-2 initially uses the node being expanded as the cv-node. This allows matching of the constraint before the plot
is processed (e.g., while checking the precondition). When the plan nodes are created from the plot, the system then begins
using 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 a level 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 first level, produce, or consume predicate it
finds that has either numerical1 or continuous1 as 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 S IPE –2. These are produce, consume, level,
level <, level >, level <=, and level >=. 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 S IPE –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 contain level, produce, and
consume predicates. All five level 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. Examples 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 not accomplished 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.
2 Some users may want a more detailed description of the evaluation of a current-value constraint. Briefly, the constructed level predicate is matched by worldcollect 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, we
can get the argument corresponding to numerical1 and use its summary-range constraint (or instantiation) on numerical1 to
enforce the current-value constraint.
162
Operator: Fuel-Puton
Arguments: 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 Parallel
Process
Arguments: block1,object1,robot1,numerical1;
Resources: block1;
Effects: (on block1 object1),
(consume robot1 numerical1);
Problem: Prob1
Goal
Arguments: block1 is not A, B;
Goals: (on block1 B);
Goal
Arguments: 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 S IPE –2 through the use of level, 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. S IPE –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 S IPE –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 S IPE –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 to accomplish the actions
of this operator (i.e., enough fuel to move block1). 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, the level > 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 a level predicate. As actions are performed, they use and replenish fuel. An action that uses fuel simply specifies, in its effects, a consume
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 a consume predicate 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 a produce 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 a level specification overrides previous produce and consume
predicates, in the sense that the system will no longer look at them to calculate the fuel level, which is
now given by the level predicate.
18.5.2
Recursive Accumulation
It has been common in S IPE –2’s domains of application to use numerical level 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-boom
Arguments: 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: boom1
Precondition: (in-service boom1)
Plot:
Parallel
Branch 1:
Goal: (located boom1 sensitive-area1)
Process
Action: locate-deploy-boom
Arguments: 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 Parallel
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 the level >= 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 than constraint). Numerical2 is the length of this boom. The plot then deploys this boom
and recursively posts the same level >= 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 of Numerical2 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 a level goal true, i.e., the actions phantomize the goal. Thus, several actions that produce
or consume quantities will phantomize such a goal by being ordered before the level phantom. The
planner, therefore, removes all such orderings to a level 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. The level phantom becomes a goal, and its solution should achieve the intended effect.
This algorithm is justified as follows. Of the N actions achieving the level 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, S IPE –2 eliminates these M entirely and changes the level
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 the Planning command in the Profile
menu.
18.6 Temporal Reasoning
By itself, S IPE –2’s temporal reasoning capability is primitive, but S IPE –2 has been extended to cooperate 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. However, Tachyon assumes each node has a non-zero duration, so S IPE –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 S IPE –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 S IPE –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 relationship before or meets with its successor plot node. A second method of adding
temporal constraints in an operator is to use the constraints slot. 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 name earliest-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
start-time
end-time
duration
Distinguished Classes
earliest-start latest-start start-time
earliest-end latest-end end-time
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 of earliest-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 should
be called before any operators or the sort hierarchy are defined as it defines temporal classes. The
keywords give the values for three of the global variables described in the next section. Tachyon
provides the value for *use-tachyon* (nil T :before :after). Merge provides the
boolean value for merge-final-time-sources, and generate provides the boolean value for
*generate-interval-constraints*.
[Function]
disable-temporal-reasoning
This function disables temporal reasoning by rsetting several global variables to their default values.
When temporal reasoning has been enabled, the class time-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 name time-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.N
shortest-duration.N longest-duration.N
167
These time-tuple variables can occur in the arguments list of an operator or plot node, in the arguments of a predicate, or in the arguments of a function constraint. If time-tuple.1 appears in the
arguments of an operator, then the rest of the operator can refer to variables earliest-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.1
earliest-end.1 latest-end.1
shortest-duration.1 longest-duration.1)
18.6.2
Temporal reasoning with Tachyon
The SIPE-Tachyon interface was completely rewritten in version 4.11 of S IPE –2. S IPE –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. S IPE –2 also make use of new Tachyon features regarding
hierarchical nodes, but such uses are not described in this document. S IPE –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 S IPE –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 S IPE –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 S IPE –2:
*use-tachyon*
[Variable]
If this variable is NIL (the default), S IPE –2 does not call Tachyon or write files for it. If this variable is
T, 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 value
of :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 pathname
that is the value of this variable. The default is “arpi:bin;”. The user should have read/write
permission in this directory.
skip-tachyon-time-windows
[Variable]
Tachyon sometimes cannot recognize its own solution to temporal constratins as a solution. (The
Tachyon implementors said this is a rounding error.) If this variable is T (the default is NIL), S IPE –2
does 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 to T if Tachyon finds
constraints inconsistent that if previously determined were consistent.
168
merge-final-time-sources
[Variable]
If this variable is non-nil (the default), then S IPE –2 merges the planner-generated constraints and the
Tachyon constraints for any time window that is not instantiated in the final plan. If this variable is
NIL, 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 causes
Tachyon 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 (the
default).
When drawing and printing plans, S IPE –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 planning decisions. The function update-tr-constraints can be called to update the temporal constraints at any time. S IPE –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 the constraints slot 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 S IPE –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 constraints 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 first overlaps 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, S IPE –2 also provides a capability to do temporal reasoning with different 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 reasoning. A complex scheme was used in S IPE –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 reasoning 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.
S IPE –2 now provides the option we call duration-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 be NIL (the default) to use Tachyon, and T for using duration as
uncertainty.
Using this option, S IPE –2 automatically adds the following hard constraints to individual actions
with 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-airforce
Arguments: 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: mobilize
Arguments: 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 Parallel
Process
Action: join-aggregate
Arguments: airforce1,airfield2,cargobyair1,cargobysea1,end-time1;
Effects: (at airforce1 airfield2)
(not (at cargobyair1 airfield2)) (not (at cargobysea1 airfield2))
Figure 18.5: Sipe Operator with Tachyon Temporal Constraints
171
Operator: transport-craft-to-beach
Arguments: craft1,beach1,
earliest-start1, latest-start1, earliest-end1, latest-end1,
shortest-duration1 is (shortest-water-transport-duration
craft1 beach-approach1
longest-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 beach1
earliest-start1 latest-start1 earliest-end1 latest-end1
shortest-duration1 longest-duration1)
Plot:
Goal: (approach-to-beach-cleared beach1 military-unit1)
Process
Action: transport-craft
Arguments: 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))
Figure 18.6: Sipe Operator using Duration-as-Uncertainty
The temporal variables are specified by using the distinguished classes in Figure 18.4 as arguments
to operators. If a variable in class duration is present, then it represents both shortest-duration and
longest-duration (which are thus equal). A variable in class start-time can be used in place of
both earliest-start and latest-start variables, and similarly for end-time. Each plot node in an operator
should have only one variable from any one temporal class in its arguments. Figure 18.6 is an example
of an operator using duration-as-uncertainty temporal reasoning.
The above constraints are not consistent with Tachyon, and only the first two are the same as Tachyon
constraints. They are used only when S IPE –2 is doing the temporal reasoning without Tachyon, as
directed by the following variables.
*duration-as-uncertainty*
[Variable]
The value of this variable must be NIL (the default) to use Tachyon, and T for using duration as
uncertainty.
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 in
operators when they are first parsed. The default value is NIL, which is generally used for Tachyon.
However, the value can be one of :start :end :duration while using Tachyon, in which case
the specified pair of temporal constraints become hard constraints in the operator. When using
duration-as-uncertainty, the value can still be such a singleton, or it can be a list of any subset of these
three values. Generally, all three are used.
*generate-earliest*
[Variable]
The value of this variable should be one of :both :earliest :latest, with :both being the
default. This variable applies only to constraints generated automatically as directed by the previous
variable.
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 management
system. 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. In Proc. of the 1986 National Conference
on Artificial Intelligence, pages 354–359, American Association for Artificial Intelligence, Menlo
Park, 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 Fifth
International Conference (KR ’96). Morgan Kaufmann Publishers, 1996.
[5] Karen L. Myers. User Guide for the Advisable Planner. Artificial Intelligence Center, SRI International, 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. Computational Intelligence, 14(2):151–187, 1998.
[8] David E. Wilkins. Practical Planning: Extending the Classical AI Planning Paradigm. Morgan
Kaufmann Publishers Inc., San Francisco, CA, 1988.
[9] David E. Wilkins. Can AI planners solve practical problems?
6(4):232–246, 1990.
Computational Intelligence,
[10] David E. Wilkins and Karen L. Myers. A common knowledge representation for plan generation
and 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 and
reacting 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 file
sipe/input/blocks.sipe.
There is another file in the distribution, sipe/input/blocks-fuel.sipe, which extends the
blocks world as a test domain for numerical capabilities of S IPE –2. It is a blocks world where moving a
block uses up units of fuel as a function of the size of the block. There are extraneous operators to show
use of syntax. In PROB1 the robot must move some block other than A onto B and have fuel remaining
in the range of [5, 50]. Thus, it must first move A off B. To accomplish this, it must move a light
block 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 numerical
object. 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: objects
SUBCLASSES: blocks,supports
END CLASS
OBJECT: a
PARENT-CLASS: blocks
PROPERTIES:
COLOR = green, SIZE = 5
END OBJECT
CLASS: blocks
PARENT-CLASS: objects
SUBCLASSES: redblocks,blueblocks
INSTANCES: a,b,c,d,e
END CLASS
175
CLASS: redblocks
INSTANCES: r1,r2
END CLASS
CLASS: blueblocks
INSTANCES: b1,b2,b3
END CLASS
CLASS: supports
PARENT-CLASS: objects
INSTANCES: table
END CLASS
STOP
(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: puton1
ARGUMENTS: block1, object1 is not block1
PURPOSE: (on block1 object1)
PLOT:
PARALLEL
BRANCH 1: GOALS: (clear object1)
BRANCH 2: GOAL: (clear block1)
END PARALLEL
PROCESS
ACTION: puton
ARGUMENTS: block1, object1
RESOURCES: block1
EFFECTS: (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 again
OPERATOR: cleartop-recurse
ARGUMENTS: object1, object2 is not object1, block1
PURPOSE: (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:
PROCESS
ACTION: puton
ARGUMENTS: block1, object2
176
EFFECTS: (on block1 object2)
GOAL: (clear object1)
;following not needed, here to show use of GENERATE-GOALS
; and an alternative specification of previous operator.
OPERATOR: cleartop-generate
ARGUMENTS: block2,object2 is not block2, block1
PURPOSE: (clear block2)
;; following optional, use for advice
PROPERTIES: FEATURES = (clearing-block generate-clear),
ROLES = ((RECEPTOR . object.2));
PLOT:
PROCESS
ACTION: generate-goals
GOALS: (on block1 object2)
PATTERN: (on block1 block2)
ARGUMENTS: object2
PROCESS
ACTION: cleared
ARGUMENTS: block2
EFFECTS: (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 achieved
END PLOT
END OPERATOR
;;;; ====================== Deductive operators ==========================
INIT-OPERATOR: DCLEAR-INIT
ARGUMENTS: block1, object1, object3 CLASS EXISTENTIAL
TRIGGER: (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: DCLEAR
ARGUMENTS: object1,object2 CLASS blocks, object3 CLASS EXISTENTIAL
TRIGGER: -(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: NOTON
ARGUMENTS: object1,object2,object3
TRIGGER: (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: ONCLEAR
ARGUMENTS: object1,block1
TRIGGER: (on object1 block1)
EFFECTS: -(clear block1)
END STATE-RULE
STOP
(init.deduce)
(DEFINE.PROBLEM)
PROBLEM: PROB2
PARALLEL
BRANCH 1: GOAL: (on a b)
BRANCH 2: GOAL: (on b c)
END PARALLEL END PROBLEM
PROBLEM: PROB4
PARALLEL
BRANCH 1: GOALS: (on blueblock3 blueblock4)
BRANCH 2: GOALS: (on redblock3 redblock4)
END PARALLEL END PROBLEM
STOP
;; example use of text descriptions
’((puton (1 2) "Put Ã on Ã")
(puton1 (1 2) "Achieve getting˜% Ã on Ã")))
(setq *GOAL-DOCUMENTATION-STRINGS*
’((on (2 1 2) "Get Ã on Ã")
(clear (block) "Clear the top˜% of Ã")))
’((on (2 1 2) "Ã is on Ã")
(clear (block) "Ã 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
: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-advised ’((generate-clear . T))
:text "When clearing a block, use generate-goals"))
(defparameter recursive-clear
(create-advice
:polarity T
:id :recursive-clear
: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-E
generate-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 and
Cannibals Problem
This appendix presents a S IPE –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-banks
INSTANCES: left-bank, right-bank END CLASS
CLASS: people
INSTANCES: cannibals, missionaries END CLASS
CLASS: boats
INSTANCES: two-people-boat END CLASS
STOP
(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 PREDICATES
STOP
(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-RIGHT
ARGUMENTS: continuous1, numerical1 is previous value of continuous1,
continuous2, numerical2 is previous value of continuous2,
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)
OPERATOR: SEND-TRIP-TO-LEFT
ARGUMENTS: continuous1, numerical1 is previous value of continuous1,
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)
OPERATOR: END-MC
ARGUMENTS: numerical1, numerical2, numerical3, numerical4, river-bank1;
PRECONDITION: (level missionaries left-bank 0)
(level cannibals left-bank 0);
PLOT:
PROCESS ACTION: no-human-stew
EFFECTS: (move-everybody);
;;================================= Move Operators =================
OPERATOR: MOVE-MC
ARGUMENTS: numerical3, numerical4, numerical1, numerical2, river-bank1,
numerical5 is (sipe+ 1 numerical1),
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-mc
EFFECTS: (on two-people-boat river-bank1)
(produce cannibals river-bank1 1)
(produce missionaries river-bank1 1)
(state numerical5 numerical6 numerical7 numerical8 river-bank1)
OPERATOR: MOVE-2-C
numerical8 is (sipe+ 0 numerical2), river-bank2 ;
(level>= missionaries river-bank1 numerical6));
182
PLOT:
PROCESS
ACTION: row-2-c
(state numerical6 numerical8 numerical5 numerical7 river-bank1);
OPERATOR: MOVE-1-C
numerical8 is (sipe+ 0 numerical2),river-bank2;
(level>= missionaries river-bank1 numerical6));
PLOT:
PROCESS
ACTION: row-1-c
ARGUMENTS: numerical3, numerical4 ,numerical1, numerical2, river-bank1;
OPERATOR: MOVE-2-M
numerical7 is (sipe+ 0 Numerical3),
numerical8 is (sipe+ 0 numerical1), river-bank2 ;
(level<= cannibals river-bank2 numerical5)),
(level<= cannibals river-bank1 numerical6);
PLOT:
PROCESS
ACTION: row-2-m
OPERATOR: MOVE-1-M
183
numerical8 is (sipe+ 0 numerical1), river-bank2;
(level<= cannibals river-bank2 numerical5)),
(level<= cannibals river-bank1 numerical6);
PLOT:
PROCESS
ACTION: row-1-m
(state numerical8 numerical6 numerical7 numerical5 river-bank1)
;;========================== Causal Theory ============================
CAUSAL-RULE: ON-BANK-NOT-ON-OTHER-BANK
ARGUMENTS: 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-CANNIBALS
ARGUMENTS: cannibals, river-bank1, numerical3, river-bank2;
TRIGGER: (produce cannibals river-bank1 numerical3);
EFFECTS: (consume cannibals river-bank2 numerical3);
END CAUSAL-RULE
CAUSAL-RULE: PRODUCE-AND-CONSUME-MISSIONARYS
ARGUMENTS: missionaries, river-bank1, numerical3, river-bank2;
TRIGGER: (produce missionaries river-bank1 numerical3);
EFFECTS: (consume missionaries river-bank2 numerical3);
END CAUSAL-RULE
STOP
(DEFINE.PROBLEM)
PROBLEM: mc3-a
Goal: (move-everybody)
END PROBLEM
STOP
184
;; Define some DOCUMENTATION STRINGS for text descriptions
’((row-1-m (5) "Row 1 missionary˜% to Ã")
(row-2-m (5) "Row 2 missionaries˜% to Ã")
(row-2-c (5) "Row 2 cannibals˜% to Ã")
(row-1-c (5) "Row 1 cannibal˜% to Ã")
(row-mc (5) "Row 1 cannibal and 1 missionary˜% to Ã") ))
’((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 S IPE –2 mobile-robot world. The input files for this world can be found in
the S IPE –2 distribution in the directory sipe/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 for
room-level path planning.
(ADJ LOCATION LOCATION) These predicates are given for all adjacent locations where neither
has anything AT them (in which case ADJ can be deduced from ADJ-LOC). Commutes are also
deduced. 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 to accomplish
DELIVER actions.
(ONPATH LOCATION LOCATION LOCATION) These predicates give intermediate locations between two nonadjacent locations. Used for path planning. Commutes are deduced.
(DOOR-LOC BORDER AREA LOCATION) All DOOR-LOCs are deduced whenever appropriate
INROOM or ADJ-LOC predicates are added. They tell which location in each room is next to the
given 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 its
AT deduced. AT is used during planning to know locations at the lowest level. Many other things
are 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 including doors (ONs are deduced). They tell which locations an object is adjacent to and are used for
getting next to objects. During planning these are deduced from ATs.
(INROOM OBJECT AREA) Most initial INROOM predicates are deduced. Every object that is ON
something has INROOM deduced. INROOMs are deduced for all locations next to objects in
rooms (not doors), and locations where objects are AT. Thus an unoccupied location not next to
any object must give its INROOM, this happens primarily in halls.
(CONTAINS LOCATION AREA) These predicates are deduced initially for locations that are ADJLOC to an object or ones which have an object at them. (Most are deduced.) They are used to
coordinate levels of abstraction, and are therefore posted for uninstantiated LOCATION variables
when we know their room without knowing their instantiation.
(OPEN BORDER) These predicates are given initially for borders, and are used to make sure the
borders are not closed.
(ON OBJECT SUPPORT) These predicates are given initially and trigger many deductions. They are
used 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 location 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 S IPE –2 input syntax. It has not been verified, and the S IPE –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
number represents any number and sexp represents any s-expression. The j 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 braces fg designate optional elements.
In many parts of S IPE –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 blocks are blocks that start with a keyword and end with the expression end keyword. Examples of keywords that start definition blocks include: class object operator state-rule
causal-rule. In a S IPE –2 input file, any Lisp expression may be included anywhere except within
a definition block. Such expressions are evaluated during loading.
In S IPE –2’s language, colons (:) and semicolons (;) are always optional. Use them to make a file
more readable. We suggest putting colons after each 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 a sipe-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 its Goals 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 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.
D.2
Domain, Predicate, and Problem Definitions
[Function]
define.domain
This function starts S IPE –2’s parser for reading the sort hierarchy, operator definitions, and world predicates. The parser controls input until it sees the symbol stop at the top level (i.e., not within a definition). There may be any number of define.domain commands, except that each file must have a
beginning define.domain and a corresponding stop. Any input so surrounded may be in a separate
file, but the description of the sort hierarchy must be loaded first.
[Function]
define.problem
This function starts S IPE –2’s parser for reading problem definitions. The parser controls input until it
sees the symbol stop at the top level. Any number of define.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 (S IPE –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
problem.def
::= (define.problem) problem stop
domain.def
problem
::= problem prob-name f;g plot end problem
pred-decls
::= [[ static-decl j open-decl j closed-decl j function-decl ]]
static-decl
open-decl
::= static-predicates ( pred-name )
::= open-predicates [( pred-name ) j t]
closed-decl
function-decl
::= closed-predicates ( pred-name )
::= no-range-functions ( fun-name )
predicates
::= [[ predicates predlist end predicates j
additions predlist end additionsj
initial-additions predlist end intiial-additions
]]
[Keyword]
predicates
This keyword indicates the predicates following it will be placed in a newly created world.
[Keyword]
additions
This keyword indicates the predicates following it will be added to an existing world.
[Keyword]
static-predicates
This keyword is followed by a list of predicate names and declares them as static.
[Keyword]
open-predicates
This keyword is followed by t or a list of predicate names and declares them as open predicates. A value
of t makes all predicates be open by default; closed predicates must then be declared as exceptions.
[Keyword]
closed-predicates
This keyword is followed by a list of predicate names and declares them as closed predicates. It is not
needed unless an “open-predicates t” declaration has been made.
[Keyword]
stop
This keyword signals the end of a define.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-op j rule j causal-rule]
real-op
rule
::= operator op-name f;g args [[ resources j instantiate j purpose j
precondition j t-constr-slot j prop-com ]] fplotg end operator
::= rule-type op-name f;g args [[ trigger j effects j condition j
causal-rule
prop-com ]] end rule-type
::= causal-rule op-name f;g args
[[ trigger j
rule-type
effects j condition j precondition j prop-com ]]
end causal-rule
::= [state-rule j init-operator j init.operator j both.operator]
trigger
::= trigger pred f;g
pattern
goals
::= pattern pred f;g
::= goals pred f;g
purpose
::= purpose pred f;g
precondition
condition
::= [precondition j preconditions] predlist
::= condition predlist
effects
t-constr-slot
::= constraints: ftconstraintg f;g
predlist
pred
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
point
::= later j later-eq j earlier j earlier-eq j equals
::= start j end
node
node-name
::= ( node-name f . integerg)
::= op-name j pred-name
plot
::= plot [copy j plot.step] end plot
192
plot.step
::= [goal.step j shortgoal.step j proc.step j cproc.step j par.step j parexp.step j
cond.step j choice.step ]
goal.step
::= fgoal goal.modg goals
shortgoal.step ::= [goal j goals] pred f;g fgoal.modg
goal.mod
::= [[ delay j external-condition j resources j sresources j args j protect j
effects j time j prop-com ]]
proc.step
parexp.step
::= process action op-name f;g fproc.modg
::= process action parexp f;g fparexp.modg
cproc.step
parexp
::= choiceprocess action op-name f, op-nameg f;g fproc.modg
::= [generate-goals j parallel-loop]
parexp.mod
::= [[ delay j delay-execute j external-condition j args j protect j
proc.mod
goals+ j pattern+ j prop-com ]]
::= [[ delay j delay-execute j resources j sresources j args j protect j effects j
time j prop-com ]]
par.step
::= parallel fprop-comg branch end parallel fprop-comg
branch
cond.step
::= branch number plot
::= cond fprop-comg condbranch end cond fprop-comg
condbranch
::= condpattern number pred f;g plot
protect
time
::= [protect-until j purpose] [purpose j predlist]
::= [[ [start-time j stop-time j duration] numerical ]]
operator op-name
[Keyword]
Operators are the actions that S IPE –2 is trying to choose among and order to solve a problem. SIPE –2
interns the op-name and makes it point to the structure designating the operator. Inspect the value of
op-name to see the internal representation of the operator.
branch number
condpattern number
[Keyword]
[Keyword]
These keywords declare the beginning of a new parallel or conditional branch. The number following
them is for readability only. S IPE –2 ignores the number, so it could be anything and there is no need to
number the branches in any particular order.
[Keyword]
copy
Copy directs the system to copy the previous node instead of expanding it. Copy should be the only
step in the plot since S IPE –2 ignores anything following it.
193
D.4
Sort Hierarchy
[Variable]
sort-hierarchy
The root class of the sort hierarchy.
S IPE –2 generates a root node which is pointed to by the global variable sort-hierarchy. Any input
class that has no parent becomes a subclass of the root.
class class-name
[Keyword]
Defines the class class-name in the sort hierarchy. S IPE –2 classes define sets not individuals, i.e. the
system 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 default
properties for whole sets of individuals. S IPE –2 interns class-name which points to the structure designating the class. Thus, one can inspect the value of class-name to see the internal representation of the
class.
object instance-name
[Keyword]
Synonyms are instance and inst. Define the object instance-name in the sort hierarchy. S IPE –2
interns instance-name which points to the structure designating the instance.
The syntax for the sort hierarchy is
sort.hier
::= class.def j instance.def
class.def
::= class class-name [[ parent.dec j subclass.dec j instance.dec j prop-com ]] end
parent.dec
class
::= [parent j parent-class] class-namef;g
subclass.dec
instance.dec
::= subclasses class-name f, class-nameg f;g
::= [insts j instances] object-name f, object-nameg f;g
instance.def
::= ob-token object-name [[parent.dec j prop-com ]] end ob-token
ob-token
parent.dec
::= [object j instance j inst]
::= [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
resources
::= arguments arg.def f, arg.defg f;g
::= resources arg.def f, arg.defg f;g
sresources
instantiate
::= [sresources j sharedresources] arg.def f, arg.defg f;g
::= instantiate arg.def f, arg.defg f;g
prop-com
::= [[ properties j comment ]]
properties
prop.dec
::= properties prop.dec f, prop.decg f;g
::= prop-name = sexp
comment
::= comment sexp
pred-arg
::= [literal-arg j arg-name]
arg.def
literal-arg
::= [literal-arg j named-arg]
expr-form
::= (expr sexp)
numerical
function
range
named-arg
::= arg-name fconstraintg
constraint
::= class-con j quant-con j is-con j with-con j with-eq j same-con
class-con
::= [of type j class] class-name
quant-con
is-con
is-not
is-current
::= class [existential j universal]
::= not [[of type class-name] j object-name j (object-name) j arg-name]
::= [current j previous] value of arg-name
with-eq
with-con
::= with prop-name fequal tog [numerical j arg-name j sexp]
::= with prop-name [greater j =greater j less j =less] than [nu-
same-con
merical j arg-name ]
::= same fasg arg-name
195
Appendix E
Correspondence of SIPE-2 and ACT
Syntax
This appendix briefly describes how an operator or plan in S IPE –2 is translated to ACT. This information
may be useful for an ACT user trying to understand S IPE –2 syntax or a S IPE –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. Tables E.1 and E.2 show the correspondences for plans and operators, respectively. Note that the computation 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 with parallel-links
(see Chapter 16), split nodes, and join nodes, must be translated to parallel nodes. Nodes of types
cond, endcond, and condpattern 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
Goals of Problem
All resources declared in plan
World predicates on which plan depends
Properties
Comment
ACT Environment Slot
Achieve Metapredicate in Cue slot
Use-Resource slot
Precondition and Setting slots
Properties slot
Comment slot
Table E.1: Correspondence of Plans to ACT Slots
196
Operator Slot
Type
Purpose
Resources
Arguments/constraints
Precondition
Time-constraints
Instantiate
Properties
Comment
ACT Environment Slot
Class property in Properties slot
Achieve metapredicate in Cue slot
Use-Resource slot
Test metapredicate in Setting Slot, Properties
Test metapredicate in Precondition slot
Time-Constraints property in Properties slot
Instantiate property in Properties slot
Properties slot
Comment slot
Table E.2: Correspondence of Operator Slots to ACT
Plot Node Slot
Action
Goals
Goals
Goals
Protect-Until
Effects
Deduce
Comment
Properties
Type of Plot Node
Process, Choiceprocess
Goal with External-Condition
Precondition, Condpattern
Goal, Phantom
all
all
all
all
all
ACT Metapredicate
Achieve-By metapredicate
Wait-Until metapredicate
Test metapredicate
Achieve metapredicate
Require-Until metapredicate
Conclude metapredicate
Conclude metapredicate
Comment metapredicate
added as tuples
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 named tuples.
Finally, operators also require translation of constraints on variables. The constraints listed in Section 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
CLASS EXISTENTIAL
CLASS UNIVERSAL
CLASS class
OF TYPE class
IS NOT instance
IS NOT OF TYPE class
WITH attr value
WITH attr EQUAL TO value
WITH attr NOT EQUAL TO value
WITH attr GREATER THAN num-val
WITH attr LESS THAN num-val
WITH attr =GREATER THAN num-val
WITH attr =LESS THAN num-val
IS CURRENT VALUE OF var1
IS PREVIOUS VALUE OF var1
ACT Slot
Properties
Properties
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Setting
Property/Setting Formula
VARIABLES
VARIABLES
(CLASS class)
(CLASS class)
(not (= instance))
(NOT (CLASS class))
(= (attr var) value)
(= (attr var) value)
(not (= (attr var) value))
(> (attr var) value)
(< (attr var) value)
(>= (attr var) value)
(<= (attr var) value)
(= var (current-value var1))
(= 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 S IPE –2 functions and indexes the source code. First, toplevel 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 as sjcontext 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 S IPE –2 data structures are of central importance
and are given next. The description of plan and plot nodes refers to variables which are varptrs in plans
and vardeses in 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 S IPE –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 by solve-act after the Act has been translated to a S IPE –2 problem.
The global variable *act-interactive* can be used to give a global default for the mode keyword in solve-act and generate-plan. The mode determines whether plan generation within
these two functions is done interactively, automatically, or in “movie mode”. When planning is automatic, solve is called by generate-plan after the problem has been translated to a partial plan (by
initialize-problem).
*act-interactive*
[Variable]
This value is T for interactive planning, NIL for automatic planning, and :movie for planning in
movie mode. It supplies a global default for the mode in solve-act and generate-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 package
or a string. A plan (or plans) is generated to solve this problem. If return-act is non-nil, the last
plan generated is translated to an Act, and the name of the Act is returned; otherwise the name of the
plan is returned. If a plan cannot be found, NIL is returned. If multiple plans are found, a list of plan
objects 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 T
for interactive planning, NIL for automatic planning, and :movie for planning in movie mode. The
keywords after mode apply only to automatic planning and are passed on to solve.
This function calls generate-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 S IPE –2 problem to be solved. The return values and keyword arguments are the
same as for solve-act.
solve-problem problem-name &key plan (depth-limit *default-depth-limit*)
(multiple-plans multiple-answers) (number-plans number-of-answers)
partial-plan-at-level (time-limit *time-limit*) start-time in-progress plan-delayed-goals
[Function]
This function calls solve after converting the given named problem to a partial plan suitable for
solve, after copying the problem for future use. The named problem must already be defined in
S IPE –2’s internal representation. It is similar to generate-plan (which is used for servers), except
for 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 for solve. Additional keyword arguments are in-progress, a boolean which causes the task network denoted by problem-name to
be solved immediately with no copy made, and plan-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-plans number-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 by initialize-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 function solve-problem. Answers are generally
obtained from global variables. When multiple-plans is nil, this function returns the object of the
plan found, or NIL for failure. When searching for multiple plans, this function may return the object
of the last plan found or NIL 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 is NIL on failure. In addition,
the global variables *current-plan* and lastplanhead are set to the plan object and planhead
of the last plan found (with the former being NIL 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 for each plan
is generated (planning continues without user interaction). If T, 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 or NIL and is only used if multiple-plans is non-nil. The
system will stop when this many plans have been found. If the value is NIL, the entire search space will
be explored when multiple plans are requested.
Partial-plan-at-level is an integer or NIL. 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
Continue and Continue-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 if time-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 that solve is invoked.
initialize-problem problem-name &key automatic
[Function]
Problem-name is the name of a S IPE –2 problem to be solved. This function translates it to a partial
plan, suitable for solve. This involves copying the problem, renaming it, doing deductions, checking
phantoms, and creating a plan object. If automatic 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 problems 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 the
list worlds. The plot form is a list structure version of the S IPE –2 syntax, with no punctuation, the
labels after end omitted, and a list around each predicate and around each parallel and cond group.
There must be an end for each parallel and cond 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.
[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 S IPE –2 was reset. It also notes
the file as loaded by S IPE –2. For SIPE –2 to notice that a file is loaded, it must be loaded by lfile,
load-new-file, load-and-update, or the Input command.
load-and-update filename
[Function]
Always loads the given file and notes it as loaded by S IPE –2.
[Function]
lfile
Prompts the user for a filename and loads the given file using load-and-update.
eval-load filename
[Function]
This is the recommended function for loading S IPE –2 input files from a top-level input file. It is similar
to the Common Lisp load function, but some Common Lisp implementations switch the input stream
from the file to the terminal when expressions read from the input stream are evaluated. This function
loads 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 problem
recognizer and replanner to modify the plan to be valid in the new world. The auto-replan variable
controls whether the replanning is done in movie mode, interactively or automatically. Preds can be
a list of S IPE –2 predicate structures or a list of expressions to parse, e.g., (not (on a b)). The
replanner sets the variables *current-plan*, lastplanhead, and *current-plans* to the
resulting 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 least
one of the predicates in the goals of node. It checks that the arguments of the node can be bound to the
arguments of the operator.
print-action-for-opr node oprname &optional plan
203
[Function]
Prints the entry in the action slot of node for oprname. Prints the expansion produced or an explanation
of any failure. If no plan object provided, prints entries for all contexts.
The following functions may not be in the API.
[Function]
sipe
Puts up a menu of top-level choices of things to do. Useful when the GUI cannot be accessed The source
code gives the function names for invoking top-level modules.
[Function]
d
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 printing
data structures.
The following function is for programmers only.
expand-node operator node plan &optional skip-expan
[Function]
This function expands node by applying the operator to it, in the context given by plan, a plan object. If
there is a valid expansion (either sn existing one or a newly created expansion), the plan-object in plan
is returned, but a new CPP has been added to its context for the expansion. If the expansion fails, NIL
is returned. If skip-expan is non-nil, the arguments and preconditions of operator are checked, but no
expansion is done. If the operator was applicable, the plan-object in plan is returned unchanged. The
interactive planner allows menu-selectable breaking of this function.
F.2
Sort Hierarchy API
The following functions provide read access to the S IPE –2 sort hierarchy. By default, S IPE –2 uses
internal definitions of these functions. However, S IPE –2 includes two file that redefine these API
funtions. The file hier-gfp.lisp translates each function into GFP function calls. The file
hier-aux.lisp uses GFP but short-circuits calls to GFP when possible by directly accessing the
internal sort hierarchy. This API is low-level, in the sense that S IPE –2 uses its own inheritence algorithm. A future task is to modify S IPE –2to use a function that accesses a property with inheritence, then
add 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 subclasses).
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 class
or 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, S IPE –2 uses the API only when this variable is non-nil.
*use-gkb-sort-hierarchy*
If this variable is T, the API functions are used for sort hierarchy access.
[Variable]
F.3 Slots on Plan and Plot Nodes
id node
[Function]
type node
[Function]
Types of control nodes are Choice Dchoice Split Join Cond Endcond.
Types
of action/condition nodes are Process Goal Executed Phantom Precondition
Choiceprocess Planhead Condpattern. Control nodes only have the six slots following immediately below. Choice nodes are inserted automatically whenever S IPE –2 has a choice of
operators 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 each
branch may have different alternative expansions. Thus, a join node has many successors, one for each
possible combination of alternatives for the parallel branches that came before it. Each node following
a join node has an sjcontext 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 and
endcond nodes.
desc node
[Function]
Returns the descendants of node. This is a list of a-ele structures, with one element for each context in
which an expansion of this node was done. Each a-ele structure has slots start-node and last-node which
point to the expansion. The arguments slot saves the variable bindings used during the expansion. The
context slot is used to determine which descendant is in the current context, and its value is a list of
CPPs (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 a
plan 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 matching
join 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 value
is a list of variables.
resources operator
[Function]
This slot is a list of variables, generally a subset of arguments. It implements the notion of reusable
resource — 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 a
plan. 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 list
of the IDs of the operators. Once an operator is applied, the atom is changed to a list where the car is
the operator id and the cdr is a list of a-ele structures, which are also in the desc slot and point to the
descendants when the operator was applied, and a desription of the failure when the operator was not
applied. The function print-action-for-opr uses this information to print the result of applying
an 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 execution
monitoring 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
parallel-succ-here node
parallel-pred node
parallel-succ node
[Function]
[Function]
[Function]
[Function]
These functions return the predecessors and successors in parallel branches. Parallel-pred-here and
parallel-succ-here have pointers only to nodes at the same hierarchical level as node. Parallel-pred and
parallel-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]
type node
[Function]
Predicate nodes have a type 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 distinguished 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 arguments to the predicate. In predicate nodes that occur in operator nodes and plot nodes, this is a list of
vardeses.
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 be
used to find contexts, names, and plan objects from names and nodes.
Functions that return plan objects
find-plan-for-plan-name name
[Function]
Name is 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]
Name can be either a plan name or an action-network name. Returns first plan object that has this name
as 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 plan
object.
find-plan-for-planhead ph
[Function]
Returns first plan object that has the given planhead node as its last planhead. This function should not
generally be used, as many plans may have the same planhead node. It is provided for error recovery
when 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, else
warnings are printed, and NIL (for a NIL input or a name that is bound to NIL) or the symbol NO is
returned.
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 S IPE –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 atom control
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. If recheck
set then also checks phantoms to see that they are still true. If nobind set, 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 in vps. 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 in vps and whose second element is a varptr to instantiate it to. Varptrs in vps which 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 S IPE –2 as a critic at each 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 prednode 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 an instan 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 S IPE –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 – use compute-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 returns NIL 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 new summary-range
constraint is posted. Additional optional arguments not listed here allow other options, such as not
posting constraints. Primarily, this computes the consequences of range 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 variable no-range-functions).
213
get-attribute node attr &optional plan
[Function]
Returns the value for attribute attr 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 — use get-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 of attr 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 function doinstan should be used instead of this function.
The plan argument is used only on calls from doinstan so should not generally be given (it allows all same constraints to be collected). This function does not generally check for compatibility 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 for cpp is generally (plan-last-choice *current-plan*). For example, the not-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 a not-instan to an object named B as follows (where VP 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, S IPE –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 and posinf 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 Basics
File
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 structures
english
--------------------------------------------------------------------------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
Critics
File
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, completion
ctv-choice
--------------------------------------------------------------------------gui-menus
These files define the grasper-based GUI,
gui-functions
including command menus
gui-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 Constraints
File
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 S IPE –2 implementation for the
programmer.
S IPE –2 permits parallel 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 predecessor 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 themselves 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
S IPE –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 the parallel-pred and parallel-succ slots of a node.
For efficiency reasons, the system stores links at lower levels in the slots parallel-pred-here and parallelsucc-here when 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 to each other when parallel links are present. This algorithm is
implemented by the method plink-ok? and the function plink-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 if node1 is ordered before node2 , 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 from node1 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 incorporating the same heuristic of looking for one possible ordering that makes a predicate true. This can
still be done efficiently in S IPE –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 suspended. 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 on Application and then on Exit or interrupt the
Lisp process with two control-Cs and abort. To use S IPE –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 on Exit in the Applications
menu), thus giving control back to the original S IPE –2 GUI.
The CLIM implementation does not support the following capabilities:
Middle clicks on commands. On Symbolics, the left click often performs some command on
the currently displayed SIPE –2 structure while the middle click performs that command on any
structure selected by the user. In the CLIM implementation, the user must first draw the selected
structure and then perform the command on it.
Printing of mouse-sensitive text. Underlying data structures that are represented by printed text
cannot be accessed by clicking on the text.
The common-lisp load function cannot be used to load S IPE –2 input files because Lucid’s lisp
switches the input stream from the file to the terminal when expressions read from the input
stream are evaluated. The S IPE –2 function, lucid-load, loads files without changing the
input stream. The function eval-load does a load when not in Lucid, a lucid-load in
Lucid, and is the recommended function for loading S IPE –2 input files.
H.1 Stuck States
This section is reproduced from Chapter 10. The term stuck state refers 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 S IPE –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 S IPE –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 S IPE –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.
input.
Please edit your
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 appears 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 S IPE –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.2 Killing is done
by interrupting the Lisp process (type controls-C twice to the Lisp window), aborting to the top
level, and calling the function (run-sipe) again. If even that fails, try meta-x panic.
1 If any S IPE –2
functions are called from the break in the Lisp window, their output will often still go to the CLIM window
and not to the Lisp window where the function is called. To get the output in the Lisp window, *sipe-output* must be
bound to *debug-io*.
2 On the Symbolics, this is done by killing the correct Grasper Graphics frame in the select-P window, then typing select-G
again.
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 still accepting 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 S IPE –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 file sipe:sipe;clim-draw-methods.
Because of a bug in CLIM, dragging of nodes using the Move command 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 on Redraw in 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
*domain-choices* variable, 71
*abbreviations* variable, 56, 57
*act-interactive* variable, 200
*domain-critic* variable, 140
*domain-critic-frequency* variable, 140
*action-documentation-strings* variable, 57–
59
*domain-name* variable, 71, 87, 89, 104
*domain-problem-file* variable, 12, 104, 109
*all-plans* variable, 144
*attribute-names* variable, 57
*domains* variable, 71
*duration-as-uncertainty* variable, 170, 172
*browser-image* variable, 66, 68
*browser-options* variable, 66
*expandable-plans* variable, 38
*external-executor* variable, 77, 78
*cbg-frequency* variable, 142
*cbg-opr-list* variable, 45
*fail-on-resource-conflict* variable, 139
*flash-link-defaults* variable, 62
*check-precond-conflicts*, 142
*check-precond-conflicts* variable, 102, 120,
*flash-plink-function* variable, 138
*generate-earliest* variable, 173
142
*check-preconds-in-interp* variable, 102, 120,
*generate-interval-constraints* variable, 167,
173
142
*copy-comment-down* variable, 108
*copy-comment-from-opr* variable, 108
*gkb-kb* variable, 89
*goal-documentation-strings* variable, 57–59
*independent-goals* variable, 137
*copy-comment-to-expansion-purpose*
able, 108
*init-problem-function* variable, 135
*instantiation-function* variable, 33
vari-
*copy-properties-down* variable, 108
*copy-properties-from-opr* variable, 108
*interactive-res-conflict* variable, 41, 138
*last-plan* variable, 144
*copy-properties-to-expansion-purpose* variable, 108
*leave-opr-args* variable, 123
*max-popup-height* variable, 67
*current-node* variable, 160
*current-plan* variable, 43, 145, 201, 203
*max-popup-width* variable, 67
*menu-for-unexpected* variable, 78
*current-plans* variable, 27, 144, 200, 201, 203
*default-depth-limit* variable, 30, 200, 201
*node-color-menu* variable, 60
*pane-color-menu* variable, 60
*default-domain* variable, 71
*describe-opr-in-popup* variable, 42, 66
*parallel-phantomize-by-addition*
140, 166
*documentation-strings* variable, 57–59
*popup-text-size* variable, 66
224
variable,
*prevent-same-solution* variable, 77, 78
*print-to-popup* variable, 66, 67
ACT command, 12, 84
ACT Options command, 14, 86
*public-domain-strings* variable, 71
*public-domains* variable, 71
Act-Editor, 8, 12–14, 19, 83, 84, 86, 91–96,
105, 107, 118, 127
*res-opr-list* variable, 45
*res-res-conflicts-only* variable, 143
act-sipe-mode function, 93
action function, 127, 131, 207
*resource-frequency* variable, 142
*retry-level-processes* variable, 79, 81
*retry-processes* variable, 79, 81
Acts, 13, 84–86, 91, 92, 94, 196
Add Facts command, 13, 43, 74
Add Goal command, 13, 43
*save-opr-arg-bindings* variable, 108
*select-replan-goal* variable, 77, 78
add-constraint function, 141, 214
add-plinks-for-time variable, 137
*select-with-completion* variable, 96
*set-node-shapes-function* variable, 61
add-protect-untils variable, 139
add-resource-constraints function, 211
*sipe-dictionary* variable, 95
*sipe-output* variable, 99
add-sipe-dictionary function, 94, 95
additions, 116, 191
*special-node-shapes* variable, 61
*tachyon-3-display-edges* variable, 169
advancesame function, 210
advice, 2, 3, 11, 60
*tachyon-format* variable, 169
*tachyon-output-path* variable, 168
Advisable Planner, 3, 31, 33, 34
Align command, 15
*temporal-frequency* variable, 143
*time-critics* variable, 102
Align-mode command, 15
ances function, 206
*time-deduce* variable, 102
*time-each-level* variable, 102
answer-names variable, 43
Application command, 9
*time-limit* variable, 30, 200, 201
*time-pc* variable, 102
apply-critics function, 211
arg-earliest-end function, 215
*unexpected-predicates* variable, 76, 80
*use-abbreviations* variable, 57
arg-earliest-start function, 215
arg-latest-end function, 215
*use-act-dictionaries* variable, 95, 97
*use-gkb-sort-hierarchy* variable, 205
arg-latest-start function, 215
arg-longest-duration function, 215
*use-tachyon* variable, 167, 168
*user-chooses-goal* variable, 41
arg-shortest-duration function, 215
args-flag variable, 56
-> ACT all command, 13, 86, 94
Argument command, 16, 22
arguments function, 120, 123, 127, 128, 131,
132, 206
-> ACT command, 13, 86
-> PRS command, 14, 86
auto-execute variable, 77–79
auto-interactive-search variable, 79
-> SIPE command, 84
A
auto-replan variable, 43, 77–79, 203
Abstract command, 13, 26, 101
225
automated-planning-display variable, 138, 202
automated-replanning-display variable, 138,
compute-s-r function, 213
cond node, 127, 196
202
Automatic command, 11, 13, 21, 23, 26, 30, 31
condition function, 120, 121
condpattern node, 127, 128, 193, 196
automatic-allocation variable, 41, 138
consume, 140, 158, 162–164
contexts, 5, 12, 27, 46, 68, 69, 101, 102, 125,
B
135, 144–146, 149, 199, 219
Continue command, 13, 24, 26, 31, 33, 35, 201
Continue-1 command, 13, 21, 26, 31, 33, 35,
Backup command, 15
big-lnlength variable, 66
Birds Eye command, 12, 54
black-and-white function, 60
36, 201
convert function, 87, 114, 115
both-operator, 118, 153
branch, 128, 193
copy, 128, 193
count-nodes function, 100
Browse command, 14, 15, 52, 53
browsing space, 53
CPP, 145, 146, 204, 206, 213, 214
D
C
d function, 65, 204
dcontext variable, 145
causal-rule, 118
causal-rules, 151
dcontext* variable, 145
debug-domain variable, 105
causal-rules variable, 65
check-pc-before-choosing variable, 41
debug-search-detailed variable, 29
debug-search-detailed-nodes variable, 29
checkcontext function, 209
choice node, 145
debug3 variable, 29
declare-proc-att function, 140
choice pane, 10, 41
choice-nodes function, 125
declare-sipe-kb function, 89
deduce function, 207
choiceprocess node, 45, 59, 127, 131, 139
choices variable, 38
default-colors function, 60
default-special-node-shapes variable, 61
class node, 111, 113, 194
Clear Plans command, 12, 104
define.domain function, 109, 117, 128, 190
define.problem function, 109, 128, 190
clg:*global-dictionaries* variable, 95
clg::act-sipe-mode function, 93
delay, 44, 82, 127, 130, 131
delay-execute, 44, 82, 127
clg::full-menu-mode function, 93
closed-predicates, 115, 117, 191
delayp function, 130
Delete Goal command, 13, 43
closed-world assumption, 115, 152
collect-footprint function, 101
desc function, 206
Destroy command, 13, 14
Colors command, 12, 59, 60
comment function, 107, 113, 121, 207
Completion command, 11, 15, 96, 97
Destroy-multiple command, 14
dictionary, 12, 13, 84, 86, 91–96
226
Dictionary command, 12, 94, 95
dinode function, 67
expand-x-layout variable, 50
expand-y-layout variable, 50
disable-temporal-reasoning function, 167
display-in-browser function, 67, 68
expandable plan, 36
expr, 125
displaypkg function, 65
dispnode function, 67
external-condition function, 127, 130, 131, 150
F
dispnode-popup function, 67
dnode function, 67, 68
doinstan function, 213, 214
fast-interactive-search variable, 30, 41, 79, 202
Find command, 12
find-applicable-operators function, 203
find-cbg-conflicts function, 211
Domain command, 11
domain files, 20
find-common-split function, 210
Find-Edge command, 15
Draw command, 14, 47, 49
Draw Objects command, 52
find-end function, 210
find-instantiation function, 211
Draw Operator command, 51
Draw Operator-Graph command, 51, 52
Find-Node command, 15
find-node-in-split function, 210
Draw Plan command, 23, 49
Draw Plan Decomposition command, 23, 50, 51
find-plan-for-name function, 144, 209
find-plan-for-plan-name function, 32, 144, 209
Draw Problem command, 49
Draw World command, 52, 57
find-plan-for-planhead function, 209
find-plan-for-planhead-context function, 209
Drawing command, 11, 14, 47, 50, 57
duration, 127
find-res-conflicts function, 211
findbegin function, 210
duration-as-uncertainty, 170
E
fix-cbg-conflicts function, 212
fix-mbt-conflict function, 212
earliest-end function, 215
earliest-start function, 215
fix-res-conflicts function, 211
flash-node-on-expansion variable, 138
effects function, 121, 127, 130, 207
Efficiency command, 11, 30, 44, 135, 141, 142
full-menu-mode function, 93
function constraint, 159, 160, 168, 213
emacs-window, 64
enable-temporal-reasoning function, 167
G
endcond node, 127, 128, 196
establishers function, 100
Generate, 133
generate-goals, 127, 131–133
eval-load function, 105, 203
Execute command, 11, 13, 79
generate-plan function, 32, 200
get-attr-vals function, 205
Execute-any command, 13
execute.primitive function, 80
get-attribute function, 214
get-attributes function, 214
get-hier-node function, 205
Execution command, 11, 76
expand-node function, 39, 101, 204
227
get-nodes function, 100
get-time-constraints function, 215
instances-api function, 205
instantiate function, 103, 120, 123, 138, 154
getvps function, 213
gkb-ed::http-kb-server function, 88
interactflg variable, 41, 138
Interactive command, 11, 13, 24, 26, 34
GKB-Editor, 8, 12, 14, 83, 86–89, 94, 105, 106,
113
Interactive-1 command, 13, 21, 26, 35, 36
J
goal node, 45, 48, 59, 79, 118, 123, 127, 131
goals function, 106, 123, 127, 131, 132, 206
graph (Grasper), 14, 19
join node, 48, 127, 196
L
graph create, 14, 20
graph destroy, 14
lastplanhead variable, 43, 65, 201, 203
latest-end function, 215
latest-start function, 215
graph input, 14
graph output, 14
Layout command, 9, 12, 24, 41
level, 77, 79, 81, 82, 140, 156, 158, 162–164,
graph select, 14
166
lfile function, 105, 203
H
Hardcopy command, 15
link-classes function, 114
List command, 12, 20
hierarchy-node-p-api function, 204
http:disable-http-service function, 88
List Files Input command, 12
List Nodes command, 12, 101, 145
load-and-update function, 105, 203
I
I-Search command, 11, 21, 23, 30, 36–38, 40
id function, 67, 120, 129, 205, 208
load-new-file function, 105, 203
longest-duration function, 215
id-api function, 204
id-flag variable, 56
ltype function, 208
indef, 125
inhibit-plan-printing variable, 77
M
Magnify command, 14, 55, 56
make-problem function, 129, 202
init-operator, 118, 153
init-operators, 151, 153
mapplan function, 210
matchcond function, 101, 212
init-operators variable, 66
init.deduce function, 116, 153
matchpred function, 212
matchvps function, 213
initial-additions, 117
initialize-problem function, 32, 200–202
mate function, 206
merge-final-time-sources variable, 167, 169
Input command, 5, 11–13, 20, 23, 105, 203
instan constraint, 68, 140
Modify command, 12, 43, 83, 87, 88, 113
mother.nature node, 43
instance, 125
instance node, 113
instances function, 113
Move command, 15
Move-group command, 15
228
output-to-emacs function, 64, 100
output-to-GUI function, 100
Movie Mode command, 21
Movie-Mode command, 13, 26, 29
Multiagent Planning Architecture, 3, 83
multiple-answers variable, 30, 200, 201
P
Parallel command, 16
N
parallel-loop, 131
parallel-pred function, 150, 207
name-context function, 209
name-flag variable, 56, 57
parallel-pred-here function, 150, 207
parallel-succ function, 150, 207
negation function, 208
New View command, 14, 22, 49–51, 56, 57
new-data-each-level variable, 136
parallel-succ-here function, 150, 207
parent function, 113
parent-api function, 205
parent-class function, 113
parent?-api function, 205
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
parguments function, 208
pattern function, 127, 131
Node Shapes command, 11, 47, 56, 60, 81
Node Sizes command, 11, 47, 55, 56
perfectworld variable, 79
phantom node, 48, 59
not-same constraint, 139, 140
notpred constraint, 140
phantomize function, 211
phantomize-by-constraints-with-ordering vari-
num-or-vp function, 161
number-of-answers variable, 30, 200, 201
able, 139
phantomize-by-constraints-without-ordering
Numerical command, 11
numerical-enabled? variable, 136
variable, 139
phantomize-choiceprocess variable, 139
numerical-template variable, 157
phantomizenet function, 211
plan object, 4, 32, 37, 46, 101, 102, 135, 143–
O
object node, 111, 113, 194
146, 199, 201, 202, 209
Planning command, 11, 27, 30, 40, 135, 166
Objects command, 12, 14, 22
old-interactive-choices variable, 38
plink-enabled? variable, 137
plot function, 121
old-plan-levels variable, 38
op-variable-names? variable, 110
pname function, 208
possible-instantiations function, 101, 213
open-predicate function, 208
open-predicates, 115, 117, 191
precondition function, 120
precondition node, 48, 59
operator, 118, 193
operators variable, 65
pred constraint, 68, 140, 158
pred function, 206
original-context variable, 146
original-cpp variable, 146
Output command, 13, 14, 19
Predecessors command, 16, 22
Predicate command, 16
229
predicates, 116, 191
predicates-not-planned variable, 109
replanner, 5, 43, 47, 59, 60, 74–77, 80, 81, 108,
137, 166, 203
predname function, 208
primitive actions, 4, 48, 59, 80, 82, 84, 86, 109
Rescale command, 15, 55, 56, 62
Reset command, 11, 12, 23, 89, 95
primitive goals, 109
Print command, 12, 13, 15, 20, 63, 65
Reshape command, 15
Reshape-group command, 15
Print Node command, 64, 67
Print Object command, 52, 64
Print options command, 13
Resource command, 16
resources function, 120, 123, 127, 131, 206
Revert command, 15
Print Plan command, 64
print-action-for-opr function, 203
run-sipe function, 24, 61, 99
S
Print-Ancestors command, 15, 23
print-footprint function, 101
s function, 24
same constraint, 140, 214
samevp function, 213
Printing command, 11, 13, 15, 63
problem recognizer, 43, 75, 79, 203
Save command, 89
save-colors function, 60
problems variable, 65
procedural attachment, 140, 141, 214
save-hierarchy function, 115
Search Space command, 11, 23, 30, 40
process node, 45, 48, 59, 77, 79, 81, 109, 118,
123, 127, 131, 139
Select command, 14, 19, 22
set-user-default-node-shapes variable, 61
produce, 140, 158, 162–164
Profile command, 92
set-user-node-shapes-from-defaults variable, 61
shortest-duration function, 215
properties function, 107, 108, 113, 121, 125,
207
sipe function, 24, 204
sipe-classes variable, 113
properties-api function, 204
protect-until, 127, 131, 139
sipe-input-keyword variable, 106, 190
sipe-ws function, 71
purpose function, 120, 121, 123, 130, 207
R
range constraint, 213
sizes variable, 55
sjcontext function, 146, 206
recheck-phan-deduce variable, 143
rededuce-oninstan variable, 137
skip-tachyon-time-windows variable, 168
sleep-time-for-movie-mode variable, 30
Redraw command, 14, 15
Regroup command, 13, 26, 149
smallest-unit-first variable, 157
Solve command, 26
remove-redundant-actions-frequency variable,
143
Rename command, 13, 14
solve function, 30, 32, 33, 200–202
solve-act function, 32, 200
Solve-problem function, 32
Reparse command, 14, 15, 50
solve-problem function, 200, 201
230
unlink-classes function, 113
update-tr-constraints function, 169
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
V
vardes, 125, 127, 199, 208
varptr, 125, 127, 141, 199, 208, 211, 213
sort-hierarchy variable, 52, 113, 194
space (Grasper), 19
verbatim-variable-names? variable, 110
Verifier, 91–94, 97
split node, 48, 127, 196
start-time, 127
start-ws function, 71
Verify command, 84, 86, 94
vp-print-id variable, 56, 66
start-www-server function, 71
state-rule, 118, 153
W
state-rules, 151
state-rules variable, 65
Web Server, 70–72, 86, 88
what-if function, 43, 203
With, 124
static-predicates, 117, 191
stop-time, 127
World command, 22
worldcollect function, 162, 212
stop-ws function, 71
stop-www-server function, 71
worlds variable, 129, 202
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
T
time-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
U
unexecute function, 80
unknown, 74, 115
231

Working Document

Transcription

Similar documents

July, 1993 - Stumpf Welding Supplies

Desoutter tools

The Continuous World of Dungeon Siege

Part 2 - SAOUG

Cut Sheet for CPICS-100 family

C.A.R. Kwikset

A Network Way of Working

Setting an Android Device to AutoFill Password Fields in