原文:https://en.wikipedia.org/wiki/Hierarchical_task_network
In artificial intelligence, the hierarchical task network, or HTN, is an approach to automated planning in which the dependency among actions can be given in the form of networks.
Planning problems are specified in the hierarchical task network approach by providing a set of tasks, which can be:
A primitive task is an action that can be executed. A compound task is a complex task composed of a sequence of actions. A goal task is a task of satisfying a condition. The difference between primitive and other tasks is that the primitive actions can be directly executed. Compound and goal tasks both require a sequence of primitive actions to be performed; however, goal tasks are specified in terms of conditions that have to be made true, while compound tasks can only be specified in terms of other tasks via the task network outlined below.
Constraints among tasks are expressed in form of networks, called task networks. A task network is a set of tasks and constraints among them. Such a network can be used as the precondition for another compound or goal task to be feasible. This way, one can express that a given task is feasible only if a set of other actions (those mentioned in the network) are done, and they are done in such a way that the constraints among them (specified by the network) are satisfied. One particular formalism for representing hierarchical task networks that has been fairly widely used is TAEMS.
A task network can for example specify that a condition is necessary for a primitive action to be executed. When this network is used as the precondition for a compound or goal task, it means that the compound or goal task requires the primitive action to be executed and that the condition must be true for its execution to successfully achieve the compound or goal task.
The best-known domain-independent HTN-planning software is:
原文:https://en.wikipedia.org/wiki/STRIPS
In artificial intelligence, STRIPS (Stanford Research Institute Problem Solver) is anautomated planner developed by Richard Fikes and Nils Nilsson in 1971 at SRI International.[1] The same name was later used to refer to theformal language of the inputs to this planner. This language is the base for most of the languages for expressingautomated planning problem instances in use today; such languages are commonly known asaction languages. This article only describes the language, not the planner.
A STRIPS instance is composed of:
Mathematically, a STRIPS instance is a quadruple , in which each component has the following meaning:
A plan for such a planning instance is a sequence of operators that can be executed from the initial state and that leads to a goal state.
Formally, a state is a set of conditions: a state is represented by the set of conditions that are true in it. Transitions between states are modeled by a transition function, which is a function mapping states into new states that result from the execution of actions. Since states are represented by sets of conditions, the transition function relative to the STRIPS instance is a function
where is the set of all subsets of, and is therefore the set of all possible states.
The transition function for a state, can be defined as follows, using the simplifying assumption that actions can always be executed but have no effect if their preconditions are not met:
= | if and | |
= | otherwise |
The function can be extended to sequences of actions by the following recursive equations:
A plan for a STRIPS instance is a sequence of actions such that the state that results from executing the actions in order from the initial state satisfies the goal conditions. Formally, is a plan for if satisfies the following two conditions:
The above language is actually the propositional version of STRIPS; in practice, conditions are often about objects: for example, that the position of a robot can be modeled by apredicate , and means that the robot is in Room1. In this case, actions can havefree variables, which are implicitly existentially quantified. In other words, an action represents all possible propositional actions that can be obtained by replacing each free variable with a value.
The initial state is considered fully known in the language described above: conditions that are not in are all assumed false. This is often a limiting assumption, as there are natural examples of planning problems in which the initial state is not fully known. Extensions of STRIPS have been developed to deal with partially known initial states.
A monkey is at location A in a lab. There is a box in location C. The monkey wants the bananas that are hanging from the ceiling in location B, but it needs to move the box and climb onto it in order to reach them.
Initial state: At(A), Level(low), BoxAt(C), BananasAt(B) Goal state: Have(Bananas)
Actions: // move from X to Y _Move(X, Y)_ Preconditions: At(X), Level(low) Postconditions: not At(X), At(Y) // climb up on the box _ClimbUp(Location)_ Preconditions: At(Location), BoxAt(Location), Level(low) Postconditions: Level(high), not Level(low) // climb down from the box _ClimbDown(Location)_ Preconditions: At(Location), BoxAt(Location), Level(high) Postconditions: Level(low), not Level(high) // move monkey and box from X to Y _MoveBox(X, Y)_ Preconditions: At(X), BoxAt(X), Level(low) Postconditions: BoxAt(Y), not BoxAt(X), At(Y), not At(X) // take the bananas _TakeBananas(Location)_ Preconditions: At(Location), BananasAt(Location), Level(high) Postconditions: Have(bananas)
Deciding whether any plan exists for a propositional STRIPS instance is PSPACE-complete. Various restrictions can be enforced in order to decide if a plan exists in polynomial time or at least make it anNP-complete problem.[2]