Domain definitions for UMCP mainly consists of 3 parts: 1. Symbol declarations, 2. Effects specifications and 3. Method descriptions.
Domain Specification
Basically, a domain specification in UMCP looks like,
(clear-domain)
...[symbol declarations].....
...[effects specifications].....
...[method descriptions].....
(load-poss-effects-table)
See Sample domain and problems for a domain definition of Blocks World.
Every symbols except task labels in domain specification must be declared explicitly in symbol declarations. (In what order these symbols are declared does not matter.)
[Note: The symbols must be declared before they are used. You can add symbols anytime by using the above functions. For example, when you want to use the constant Box-C which is not used in domain specification but used in some specific problems, you can use (constants Box-C) to declare that constant. ]
For each primitive task which has preconditions or effects.
(operator o1(arg1 arg2)
:pre (literal1 literal2 ..) ; preconditions
:post (literal3 literal4..)) ; effects
An argument is a constant or a variable.
A literal can be either positive (p1 arg1 arg2 ..) or negative (~p1 arg1 arg2).
[Note: Operator's preconditions are merged to the constraint formulas of methods when UMCP is reading methods. Notice that these preconditions are unsupervised conditions.]
(declare-method task (arg1 arg2 ..)
:expansion ((label1 task1 arg11 arg12 ..) (label2 task2 arg21 arg22 ..) ..)
:formula Constraint-Formula)
A constraint formula is either T, a single constraint , or constraints connected by AND, OR, or NOT.
vnum- variable, cnum - constant, nnum - task node label, p - predicate
| Constraint type | positive | negative |
| veq | (veq v1 v2) - the variables v1 and v2 have same value
(veq v1 c1) - the variable v1 has the value c1 |
(not (veq v1 v2)) - the variables v1 and v2 have different values
(not (veq v1 c1)) - the variable v1's value is not c1 |
| ord | (ord n1 n2) - the task labeled by n1 must be ordered before the task labeled by n2 | (not (ord n1 n2)) - the task labeled by n1 must be ordered after the task labeled by n2, or n1 =n2. |
| initially | (initially p) - p is true in the initial state. | (not (initially p)) - p is not true in the initial state |
| before | (before p n1) - p is true in the state right before the task labeled by n1 | (not (before p n1)) - p is not true in the state right before the task labeled by n1 |
| after | (after p n1) - p is true in the state right after the task labeled by n1 | (not (after p n1)) - p is not true in the state right after the task labeled by n1 |
| between | (between p n1 n2) - if n1 comes before n2, p is true throughout the every state from n1 to n2 | (not (between p n1 n2)) - n1 does not come before n1 or p is false somewhere between n1 and n2. |
| protect | (protect p n1 n2) - no task between n1 and n2 asserts ~p |
In constraints, you can specify (first n1 n2 n3) to first node in n1, n2, and n3. Similarly, you can use (last n1 n2 n3) for the last node of n1, n2, and n3.
Problem Specification
After you specified a domain, you can create a problem. UMCP requires two things: 1. an initial state specification and 2. a goal task-network.
1. Initial state
An initial state specification is a complete specification of the state before tasks can be performed. The specification is a list of positive ground atoms which are true in the initial state. Every atom which is not in the initial state specification is assumed to be false by the planner.
(initially-true atom1 atom2 atom3 ....)
2. Goal task-network
A goal or a problem is a task-network. You can create a new task-network with CREATE-TN.
(create-tn formula task1 task2 )
ex. (create-tn (and (ord n1 n2) (after (p a) n2)) (n1 move a b)(n2 drop c))
[Note: you can use variables in a goal. However, they must be declared in the variable declaration.]
Go back to Main Page