Questions about Plan Repair

[rpgoldman]

@ko56 asked some questions about plan repair, related to our paper on the subject, which was published in the 2020 Hierarchical Planning workshop (associated with ICAPS): https://hierarchical-task.net/publications/hplan/2020/HPlan2020-paper4.pdf

He has kindly allowed me to post them here so that I can answer them publicly in case they are of general interest. I've inserted my responses using the quotation operator, which means that I'm using it backwards! The unquoted questions are actually quotes from @ko56 and the quoted material is my answers.

1. My understanding is that the enhancements to SHOP3 described in the paper are not only applicable to domains written in PDDL, but to ordinary SHOP3 domains as well, albeit subject to some restrictions.  Correct?

   The enhancements described in that paper are limited to domains whose actions are written in PDDL, and whose methods are "PDDL Methods." "PDDL Methods" are methods that are pure (i.e., do not involve the use of if-then-else method forms) and have PDDL style preconditions. This is necessary in order for our flaw finding method to be complete (it is complete but not sound, so it might think that a plan requires repair when it does not).

   We are working to expand the scope of the plan repair algorithm. Doing this requires reasoning about whether preconditions will be violated in the future, which is not always possible with arbitrary SHOP preconditions, and with lifted planning, or at least not efficiently possible in the face of constructs like disjunction. So we need to provide methods for precondition evaluation in the future, and prove them sound. It was easy to do this for PDDL, which has very simple semantics. In practice, the algorithm will work with some SHOP constructs that are not in PDDL, but these are the ones we could prove correct in 2020.

2. The description of repair/replanning in sec. 4 of the paper, using "disturbance pseudo-actions", is somewhat confusing to me. The way I read it, it seems as if it applies more to plan generation as opposed to a combination of planning with acting (in the sense of Automated Planning and Acting by Ghallab, Nau, and Traverso, 2016).  I mean that when the search algorithm chooses a PDDL disturbance action at some point, this causes the plan prefix (?) to fail and triggers replanning.  But this pseudo action is intended to, somehow, correspond with an event in the external world that causes a failure in the execution of the plan, no?

   Yes, that is correct. The disturbance action just serves as a thing that we inject into the plan in order to enable us to use the already-existing SHOP facilities for predicting next state from current state and current action, instead of adding a new means of state update.

3. And planning with acting is actually the (ultimate) goal of the work in the paper. Yes?

   Yes

4. If so, do you have some ideas about how to make use of the enhanced SHOP3 in a planning-with-acting setting? I haven't come up with anything worthwhile on my own.

   We haven't come up with anything yet. We have in the past used SHOP in a planning-with-acting setting, but haven't developed a general method of executing SHOP plans. The method has always been at least somewhat specific to the execution environment.

5. Finally, I've played with find-plans-stack a bit.  What exactly is the definition of a "repairable plan"?

   A repairable plan is a data structure that contains additional annotations -- notably a plan tree with cross-links in it that record what action provides preconditions to following actions and methods. This information is not needed for SHOP3 in general, and it's at least a little expensive to compute and store, so we allow the user to decide whether they want a repairable plan or a simpler ordinary plan.

[rpgoldman]

I guess I need to add a comment to record this as answered.