Loading AI tools
Robot programming language From Wikipedia, the free encyclopedia
In artificial intelligence, action description language (ADL) is an automated planning and scheduling system in particular for robots. It is considered an advancement of STRIPS. Edwin Pednault (a specialist in the field of data abstraction and modelling who has been an IBM Research Staff Member in the Data Abstraction Research Group since 1996[1]) proposed this language in 1987. It is an example of an action language.
Pednault observed that the expressive power of STRIPS was susceptible to being improved by allowing the effects of an operator to be conditional. This is the main idea of ADL-A, which is roughly the propositional fragment of the ADL proposed by Pednault,[2] with ADL-B an extension of -A. In the -B extension, actions can be described with indirect effects by the introduction of a new kind of propositions: ”static laws". A third variation of ADL is ADL-C which is similar to -B, in the sense that its propositions can be classified into static and dynamic laws, but with some more particularities.[3]
The sense of a planning language is to represent certain conditions in the environment and, based on these, automatically generate a chain of actions which lead to a desired goal. A goal is a certain partially specified condition. Before an action can be executed its preconditions must be fulfilled; after the execution the action yields effects, by which the environment changes. The environment is described by means of certain predicates, which are either fulfilled or not.
Contrary to STRIPS, the principle of the open world applies with ADL: everything not occurring in the conditions is unknown (Instead of being assumed false). In addition, whereas in STRIPS only positive literals and conjunctions are permitted, ADL allows negative literals and disjunctions as well.
An ADL schema consists of an action name, an optional parameter list and four optional groups of clauses labeled Precond, Add, Delete and Update.
The Precond group is a list of formulae that define the preconditions for the execution of an action. If the set is empty the value "TRUE" is inserted into the group and the preconditions are always evaluated as holding conditions.
The Add and Delete conditions are specified by the Add and Delete groups, respectively. Each group consists of a set of clauses of the forms shown in the left-hand column of the figure 1:
The Update groups are used to specify the update conditions to change the values of function symbols. An Update group consists of a set of clauses of the forms shown in the left column of the figure 2:
The formal semantic of ADL is defined by four constraints.
⇒ Actions may not change the set of objects that exist in the world; this means that for every action α and every current-state/next-state pair (s, t) ∈ a, it must be the case that the domain of t should be equal to the domain of s.
⇒ Actions in ADL must be deterministic. If (s, t1) and (s, t2) are current-state/next-state pairs of action ∃, then it must be the case that t1 = t2.
⇒ The functions introduced above must be representable as first-order formulas. For every n-ary relation symbol R, there must exist a formula ΦaR(x1, ... ,xn) with free variables x2, ..., xn such that faR(s) is given by:
Consequently, F(n1, ..., xn) = y will be true after performing action |= if and only if ΦaR (x1, ..., xn,y) was true beforehand. Note that this representability requirement relies on the first constraint (domain of f should be equal to domain of s).
⇒ The set of states in which an action is executable must also be representable as a formula. For every action α that can be represented in ADL, there must exist a formula Πa with the property that s |= Πa if and only if there is some state t for which (s, t) ∈ α (i.e. action α is executable in state s)
In terms of computational efficiency, ADL can be located between STRIPS and the Situation Calculus.[4] Any ADL problem can be translated into a STRIPS instance – however, existing compilation techniques are worst-case exponential.[5] This worst case cannot be improved if we are willing to preserve the length of plans polynomially,[6] and thus ADL is strictly more brief than STRIPS.
ADL planning is still a PSPACE-complete problem. Most of the algorithms polynomial space even if the preconditions and effects are complex formulae.[7]
Most of the top-performing approaches to classical planning internally utilize a STRIPS like representation. In fact most of the planners (FF, LPG, Fast-Downward, SGPLAN5 and LAMA) first translate the ADL instance into one that is essentially a STRIPS one (without conditional or quantified effects or goals).
The expressiveness of the STRIPS language is constrained by the types of transformations on sets of formulas that can be described in the language. Transformations on sets of formulas using STRIPS operators are accomplished by removing some formulas from the set to be transformed and adding new additional formulas. For a given STRIPS operator the formulas to be added and deleted are fixed for all sets of formulas to be transformed. Consequently, STRIPS operators cannot adequately model actions whose effects depend on the situations in which they are performed. Consider a rocket which is going to be fired for a certain amount of time. The trajectory may vary not only because of the burn duration but also because of the velocity, mass and orientation of the rocket. It cannot be modelled by means of a STRIPS operator because the formulas that would have to be added and deleted would depend on the set of formulas to be transformed.[8]
Although an efficient reasoning is possible when the STRIPS language is being used it is generally recognized that the expressiveness of STRIPS is not suitable for modeling actions in many real world applications. This inadequacy motivated the development of the ADL language.[9][10] ADL expressiveness and complexity lies between the STRIPS language and the situation calculus. Its expressive power is sufficient to allow the rocket example described above to be represented yet, at the same time, it is restrictive enough to allow efficient reasoning algorithms to be developed.
As an example in a more complex version of the blocks world: It could be that block A is twice as big as blocks B and C, so the action xMoveOnto(B,A) might only have the effect of negating Clear(A) if On(A,C) is already true, or creating the conditional effect depending on the size of the blocks. This kind of conditional effects would be hard to express in STRIPS notation without the conditional effects.
Consider the problem of air freight transport, where certain goods must be transported from an airport to another airport by plane and where airplanes need to be loaded and unloaded.
The necessary actions would be loading, unloading and flying; over the
descriptors one could express In(c, p)
and At(x, A)
whether a freight c is in an airplane p and whether an object x is at an airport A.
The actions could be defined then as follows:
Action (
Load (c: Freight, p: Airplane, A: Airport)
Precondition: At(c, A) ^ At(p, A)
Effect: ¬At(c, A) ^ In(c, p)
)
Action (
Unload (c: Freight, p: Airplane, A: Airport)
Precondition: In(c, p) ^ At(p, A)
Effect: At(c, A) ^ ¬In(c, p)
)
Action (
Fly (p: Airplane, from: Airport, to: Airport)
Precondition: At(p, from)
Effect: ¬At(p, from) ^ At(p, to)
)
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.