CS 1571: Homework 10

Planning (Chapter 11): Programming (150 pts)

Assigned: November 20, 2008 (by end of day)

Due: December 4, 2008

NOTE: THIS IS STILL A DRAFT!

Partial-Order Planning

The assignment is to implement the partial-order planner described in the POP class, and test it on several planning problems. You only have to build a planner where the action schemas do not have variables. Test it on the shoes and socks problem (Figure 11.6), the flat tire problem (Figure 11.7), and a new problem that you create (which was not discussed in the text or in class). Your planner should input a set of action schemas, including the Start and Finish schemas, which specify the initial state and the goals. It should output a plan, formatted as in the discussion below. It does not need to linearize the plan. Implement a legible trace (with print statements). It should trace the develop of each plan by (1) indicating what open precondition it is working on, (2) what action (existing or new) it used to achieve it, and (3) what conflicts it found and for each, (4) how it resolved the conflict. Use some kind of numbering to make it clear where it is going when the search backs up.

Representation: Details

States of the world will be described in terms of sets of propositions, and actions will be described as operators with three lists of propositions: a precondition list (what must be true for the action to be performed), an add list (propositions that are made true when the action is performed), and a delete list (propositions that are made false when the action is performed). For example, we might describe a planning problem for a housecleaning robot as follows:

Initial state: {floor-dusty,floor-dirty, furniture-dusty}

Goal state: {floor-clean,furniture-clean}

Operators:

Sweep:
Preconds: {floor-dusty},
Add: {floor-not-dusty},
Delete: {floor-dusty}

Vaccuum:
Preconds: {floor-dusty, vaccuum-works},
Add: { },
Delete: {floor-dusty}

Wash-floor:
Preconds: {floor-not-dusty, floor-dirty},
Add: {floor-clean},
Delete: {floor-dirty}

Dust:
Preconds: {furniture-dusty},
Add:{floor-dusty,furniture-clean},
Delete: {floor-not-dusty, furniture-dusty}

We will model a plan as consisting of five components:

  • a set of steps, which are instances of actions
  • a set of temporal ordering constraints on those steps
  • a set of causal links, which represent causal relationships between steps. Formally, a causal link is a triple where si is a step in the plan that makes p true and sj is a step in the plan that has p on its precondition list.
  • a set of open conditions, which are preconditions of steps that still need to be made true;
  • a set of threats, where a threat is a . An effect of the threatening step clobbers the middle element of the causal link.

    Here is a solution plan for the problem just described.

    steps: ['init', 'goal', '0*wash-floor', '1*dust', '2*sweep']

    causal links:
    (0*wash-floor < floor-clean < goal)
    (1*dust < furniture-clean < goal)
    (2*sweep < floor-not-dusty < 0*wash-floor)
    (init < floor-dirty < 0*wash-floor)
    (init < furniture-dusty < 1*dust)
    (init < floor-dusty < 2*sweep)

    ordering constraints (other than those with goal or init):
    (2*sweep < 0*wash-floor)
    (1*dust < 2*sweep)

    no openconditions or threats

    Note that there are two reasons for the ordering constraints the plan includes. The first one, (2*sweep < 0*wash-floor), is included because of the causal link: (2*sweep < floor-not-dusty < 0*wash-floor). That is, a sweep action achieves floor-not-dusty, which is a precondition of the wash-floor action. The second one, (1*dust < 2*sweep), is included to resolve the following threat: (('2*sweep', 'floor-not-dusty', '0*wash-floor'), '1*dust') A "dust" action "clobbers" the condition "floor-not-dusty". The problem is resolved by ordering the "dust" action before the "sweep" action.

    Algorithm: Details

    In this assignment, you will construct a system that generates plans by searching through the space of partial plans.

    In a plan-space planner, you begin with a dummy initial plan that includes two steps. One represents the initial state, and it has no preconditions, but has an add list containing everything that is true initially. Essentially, the initial step makes true the initial conditions. The other step of the initial plan represents the goal state. It has no effects (i.e., its add and delete lists are empty), but its preconditions are equal to the goal propositions.

    During the planning process, you will also store information in each plan about its flaws, i.e., its open conditions and threats. The dummy initial plan has as open conditions all the preconditions of the goal step. It does not contain any threats, because it does not yet contain any causal links. The goalp test takes a plan as an argument and checks whether the plan is complete. A complete plan is one that has no open conditions and no threats.

    The heuristic function: There is much literature on how to control the search during planning. In this project, we will simply rank a plan by the number of open conditions and threats it contains, on the assumption that the fewer the number of flaws, the better. Your heuristic evaluation function should take a plan as an argument, and return the sum of the number of its open conditions and threats.

    The interesting part is the successor function. Remember that the nodes in the search space represent plans, and, until a goal node is reached, each of those plans will have some flaws: open conditions and/or threats. To produce the successors of a node, what you will do is to select some flaw, and then compute *all* the ways of correcting ("resolving") the flaw.

    Let's consider the two types of flaws, starting with open conditions. Recall that an open condition is a precondition of some step that needs to be made true. Let (C,X) be an opencondition. There are two ways to resolve an (C,X). The simplest is to find some other step, S, already in the plan that makes the condition true (i.e., S has C on its add list). For every step S already in the plan that can be re-used to achieve the selected open condition, you will create a successor node that has an additional causal link , along with an additional ordering constraint that requires S to precede X. We then need to check if there is a new threat: it is possible that another step, Y, which is already in the plan, threatens the new causal link. This happens if C is on the delete list of Y, and Y is not already ordered before S or after X. (Be careful with operators such as sweep, with dusty as a precondition and dusty as a delete. You don't want your program to think that an action threatens itself!)

    The other way to achieve an open condition (C,X) is to find an operator that makes it true, and then insert a new step S representing that operator into the plan. In this case, in the successor plan we again need to add a causal link and an ordering constraint between S and C. We've also got to add ordering constraints to ensure that S occurs between steps init and goal. We've got to add all of the preconditions of S to the set of open conditions. And, we've got to update the list of threats associated with the plan, to include any new threats that were introduced by S. That means that we need to look at the steps in the plan, to determine whether any of them delete the newly satisfied open conditions, and we need to look at all the causal links, to see if the newly inserted step deletes the propositions of any of the causal links. Remember that if there are multiple operators that can achieve the selected open condition, we will create multiple successor nodes.

    Now let's consider how to resolve threats. A threat can be viewed as having four components: a producer step, a consumer step, a condition (that the producer makes true for the consumer), and a threatening step. There are two ways of resolving threats:

  • demotion: adding an ordering constraint that requires the threatening step to precede the producer
  • promotion: adding an ordering constraint that requires the consumer to precede the threatening step.

    The last interesting complication to our planning problem: whenever we introduce a new temporal ordering constraint, we need to make sure that it is consistent. A set of ordering constraints is consistent if three conditions hold:

  • No step precedes step "init".
  • Step "goal" does not precede any step.
  • No step si precedes itself in the transitive closure of the ordering constraints. For example, you can't have s5 < s7 and s7 < s5.