Docstoc

Artificial Intelligence

Document Sample
Artificial Intelligence Powered By Docstoc
					      ICS381 Introduction to
Artificial Intelligence (AI)
            Dr. Emad A. El-Sebakhy

       Room: 22-316, Phone: 860-4263
      Email: dodi05@ccse@kfupm.edu.sa


King Fahd University of Petroleum & Minerals
  College of Computer Science & Engineering

 Information & Computer Science Department

           Tuesday, April 27, 2010
Today’s class:
                       Planning
   Planning is a fundamental capability of intelligent
    systems. Specifically:
     the ability to plan for future events
     the ability to reason (think) within a changing
      environment
     the ability to decompose complex problems into
      manageable units (small problems).


Planning is a special case of reasoning. We want
to achieve some state of the world. Typical
example is robotics
                       Planning
   For some problems the notion of planning is the
    same as a search for a solution.
     Example:    8-puzzle
   Other problem domains make the distinction
    between search and planning clear:
     those   in which the universe is not predictable.
Search vs. Planning
             Classification vs. Synthesis

       Planning problems can be:
          Classification problems: simply decide which of
          many possible actions to take.
         Synthesis problems: work out the entire solution
          before taking any steps. The end result is a formal plan
          that may be useful in future situations.

   Note:       The environment is changing, so plans must be
                constantly altered.
               Computational efficiency is important - we need
                to find ways to develop search procedures that
                take advantage of the nature of planning
                problems.
     Example - Robot Navigation
 The goal for a robot is to move from one room to
  another without bumping into obstacles.
 This is pretty easy if we assume:
     therobot has knowledge of all rooms and obstacles.
     Nothing ever changes (the knowledge is a perfect
      predictor).
   If nothing ever changes:
     create a logic database that describes everything
      about the environment.
     Use a constructive proof (resolution, keeping track of
      each relevant resolution) to create a plan.
     Realistic Robot Planning

 What if someone moves a chair?
 What if a child lays down in front of the robot
  (as children often do)?
 What if a Klingon tries to stop the the robot and
  the robot is forced to kill the Klingon, whose
  rotting corpse is now blocking the doorway (as
  Klingons often do)?
                  Reactive Systems
   The plan is - don’t bother making a plan, since a Klingon
    will always screw things up.
   Develop a subgoal, and take action to achieve the subgoal.
   Take a look at the result, devise a new subgoal.
   Keep going until we reach the goal.
   Work well for many types of very simple tasks example:
    thermostat.
   Often a combination of reaction and true planning is
    required:
      Can’t wait for the best plan before taking some action.
      Taking a really bad action can lead to disaster.
 Simple Planning vs. Reactive Systems
 A Reactive system doesn’t make a full plan, at
  each step. It just tries to get closer to the goal.
 A planning system works out an entire plan,
  then makes the first step of the plan.
 True planning involves looking ahead, which
  can result in a much shorter path to the goal.
              General Approaches
   The general idea is to make use of previous
    calculations:
        if we originally made a complete plan and now find
        something has changed - perhaps most of the original
        plan is still valid.
 We need to develop some way to represent plans
 We need algorithms to alter plans.
       Planning & Decomposition
   Problems that are decomposable or partially
    decomposable can often be solved by a system
    that:
     Can solve each sub-problem independently.
     Knows which sub-problems are not independent.
     Can revise the solutions to sub-problems when things
      don’t go according to the plan.
   This approach is what we are really interested in.
Example
                   Example
   Robot develops a plan for getting to another
    room. The plan involves:
     Moving around the couch.
     Moving from the couch to the door.
     Opening the door.
     Moving through the doorway.
              Robot State Space

 Location of all obstacles, walls, doors, rooms, etc.
 Location of the robot.
 Speed and direction of movement of robot.
 Position of all robotic perhiperals (arms, sensors,
  phaser).
Planning a set of solutions.
 Sometimes it is possible to create a number
  of plans, each of which can deal with
  specific obstacles that might arise.
 When something goes wrong, we already
  have a contingency plan ready.
 Often this is not possible or practical (the
  knowledge required is not available or is too
  large).
    Subtask Dependencies
   The plan includes information that describes the
    dependencies among all subtasks.
   Using this information to revise plans is called
    dependency-directed backtracking.
   It is often easier to determine these dependencies
    if the planning process works from the goal state
    backwards.
Example: Blocks World   ON(B,A)
                        ONTABLE(A)
                        CLEAR(B)
                        HOLDING(C)



                C
        B

        A
    Blocks World (cont.)
Predicates used to describe state:
  ON(A,B)              Block A is on block B
  ONTABLE(A)           Block A is on the table
  CLEAR(A)             There is nothing on block A
  HOLDING(A)           The robot is holding block A
  ARMEMPTY             The robot arm is empty
      Blocks World Operations
   Unstack(A,B) take block A off of block B.
   Stack(A,B)    put block A on block B.
   Pickup(A)     pick up block A.
   Putdown(A)    put block A on the table.
   Phaseit(A)    vaporize block A with a phaser.
Operation Constraints Example
Unstack(A,B):
 ARMEMPTY       the arm must be empty
 CLEAR(A)       nothing on top of A
 ON(A,B)        A must be on B
Some Blocks World Axioms

   [x : HOLDING(x)]   ARMEMPTY

   x : ONTABLE(x)    y : ON(x,y)

    x : [  y : ON(y,x)]  CLEAR(x)
        Blocks World Reasoning
 State representation is a set
  of predicates that are true for
  that state.
 Each predicate references a
  situation object:
    ON(B,A,state0)
    ONTABLE(A,state0)               B
    CLEAR(B,state0)                 A C
    ONTABLE(C,state0)
    CLEAR(C, state0)
     Blocks World & Resolution
   The effect of each operator is encoded in
    predicate logic:
    CLEAR(x,s)  ON(x,y,s) 
      HOLDING(x, Do(Unstack(x,y),s)) 
      CLEAR(y, Do(Unstack(x,y),s))

    Do is a function that specifies the state resulting
     from the application of an operator.
      State0:                    Unstack Operator
ON(B,A,state0)          CLEAR(x,s)  ON(x,y,s) 
ONTABLE(A,state0)         HOLDING(x, Do(Unstack(x,y),s)) 
CLEAR(B,state0)           CLEAR(y, Do(Unstack(x,y),s))
ONTABLE(C,state0)

CLEAR(C, state0)

             state1 = Do(Unstack(B,A), state0)

          HOLDING(B, state1)CLEAR(A, state1)
state1   = Do(Unstack(B,A), state0)
   state0

B
A C
                     state1

                              B

                    A C
          Is ONTABLE(A,state1) true ?

 The Unstack operator that produced state1
  doesn’t say anything about what was not
  changed.
 We need to add some frame axioms that specify
  what doesn’t change when each operator is
  applied.

    ONTABLE(z,s)  ONTABLE(z, Do(Unstack(x,y),s))
             Using Resolution
 In general, we need to add many frame
  axioms to make sure that all state
  information can be derived.
 If we specify all the necessary axioms,
  Resolution is the only mechanism we need.

   It is not always feasible to specify all the
    necessary axioms.
                Hybrid Approach
For each operator:
  preconditions: predicates that must be true before the
    operator can be applied (constraints).

  adds: predicates that the operator causes to become true.

  deletes: predicates that the operator causes to become
    false.

  Anything not specified is assumed to be unchanged.
Stack(x,y)
  Preconditions: CLEAR(y)  HOLDING(x)
  Adds:          ARMEMPTY  ON(x,y)
  Deletes:       CLEAR(y)  HOLDING(x)



Unstack(x,y)
  Preconditions:
  Adds:
  Deletes:
                 ONTABLE(A)  CLEAR(B) 
                 CLEAR(A)HOLDING(B) 
      B
                  ARMEMPTY

A                           +
               Adds: ARMEMPTY  ON(x,y)
Unstack(B,A)   Dels: CLEAR(y)  HOLDING(x)




B                 ON(B,A)  ONTABLE(A) 
A                 CLEAR(B)  ARMEMPTY
             Goal Stack Planning
 Divide the problem into subproblems.
 For each subproblem:
     Put   a description of the subgoal on a stack.
   While not done
     getsubgoal from stack.
     Find sequence of operators that will achieve the
      subgoal. Apply operators to current state.
   Start State      Goal State


B                C B
A C D            A D
ON(B,A)         ON(C,A) 
ONTABLE(A)      ON(B,D) 
ONTABLE(C)      ONTABLE(A) 
ONTABLE(D)      ONTABLE(D)
ARMEMPTY
                    Goal Stack
1. ON(C,A)  ON(B,D)  ONTABLE(A)ONTABLE(D)

  Get goal from stack, divide in to subgoals, put
    original goal on the stack, followed by each
    unsatisfied subgoal.

1. ON(C,A)
2. ON(B,D)
3. ON(C,A)  ON(B,D)  ONTABLE(A)ONTABLE(D)
              Subgoal: ON(C,A)
 Examine operators for one that has a
  predicate for ON in the Adds list.
 Find that Stack(C,A) does the job.
 Put Stack(C,A) on the goal stack.
     Don’tneed ON(C,A) on the stack since
     Stack(C,A) makes ON(C,A) true.
              Subgoal: Stack(C,A)
       Stack(C,A) has preconditions, put them on
        the goal stack.

1. CLEAR(A)  HOLDING(C)
2. Stack(C,A)
2. ON(B,D)
3. ON(C,A)  ON(B,D)  ONTABLE(A)ONTABLE(D)
Subgoal: CLEAR(A)  HOLDING(C)
   Separate into 2 subgoals and put on the stack.
    In this case it is clear (to us) that order can be
    very important!
1. CLEAR(A)
2. HOLDING(C)
3. CLEAR(A)  HOLDING(C)
2. Stack(C,A)
2. ON(B,D)
3. ON(C,A)  ON(B,D)  ONTABLE(A)ONTABLE(D)
         Subgoal: CLEAR(A)
 CLEAR(A) is not currently true, but
  Unstack(B,A) will make it true.
 Put Unstack(B,A) on the stack in place of
  CLEAR(A).
 Unstack(B,A) has preconditions:
     ON(B,A)  CLEAR(B)  ARMEMPTY
                Backtracking
 Dividing a goal into subgoals and putting
  each on the stack is a form of planning.
 When the solution to a subgoal screws up
  the next step, we need to backtrack.
 Backtracking is not explicitly done, but
  rather implied by the process
     each subgoal taken from the stack is solved
     relative to the current state.
               The Solution
 The solution is the sequence of operators
  that were applied.
 Since we know what each operator does
  (from the adds and deletes lists) it is
  possible to reduce a sequence of operators.

   Example: Stack(A,B), Unstack(A,B) => {}
          Nonlinear Planning
 Sometimes we need to attack multiple
  subgoals at the same time.
 Developing a plan that can do this is called
  nonlinear planning.
 Using precondition, add and delete lists
  makes it possible to determine the effect of
  interleaving solutions.
Partial-Order Plans Example

                       Start




      Left Sock                    Right Sock

LeftSockOn                                   RightSockOn


      Left Shoe                    Right Shoe


    LeftShoeOn                      RightShoeOn
                       Finish


             Principle of least commitment
Hierarchical Planning
1. Try to establish a general plan first.

2. Refine each of the steps of the plan.

3. Refine each refinement (and so on…)
Complexity
   Normal planning
     O(bn),   b branching factor and n length of plan
   Hierarchical planning
     O(bsd),   s number of non-primitive operators,
       b  number of decompositions per level
        d depth of decompositions

				
DOCUMENT INFO