This code archive contains the LPGP system (Linear-Programming and Graph-Plan) for temporal planning. There are some important things to understand before using it. It is a prototype system, most of which has not changed since 2003 (the changes are a little debugging, modifications to make it compile with newer and more standards-compliant g++ compilers, a switch to using lpsolve5.5 instead of the original lpsolve2.0 it used and some tidying up of the output). It is built on a version of STAN that was not new even in 2003.... it uses an older version of no-good recording that is expensive and was updated in more recent versions of STAN. The parser is not capable of handling significant chunks of PDDL - it was never designed to. Worse, in its LPGP form, STAN uses a specialised representation which is based on PDDL, but uses some twists to communicate some information to LPGP in a more accessible form (for the ancient parser). The good news is that it is possible to convert PDDL2.1 into the LPGP language files. This is done using two tools, both available in the VAL archive, explained below. Also note that LPGP does not deal with numbers other than durations, so the durations of actions can be dependent on the arguments of the action, but cannot be computed from other numeric fluents.

To build - you will need VAL-4.2.01 or better from the VAL archive. You will also need lp_solve_5.5 (http://sourceforge.net/projects/lpsolve) and it is assumed this is installed in a parallel directory to LPGPSTAN. If not, then you need to change the include in actions.cc and the library directive in the Makefile.

"make lpgp"

and also

"make process".

To convert a PDDL2.1 domain and problem into LPGP form and then run LPGP:

Firstly, any types must be stripped from the domain. This can be achieved using "typestrip" (in the VAL archive). You will have to do some minor editing to tidy up things like the requirements field. STAN's parser is fussy about things like use of "(and ...)" in effects and preconditions, even when there is only a single conjunct, so you might need to check this. Run with: "typestrip domain.pddl problem.pddl" and it generates "domain.pddl.untyped" and "problem.pddl.untyped". If you need to convert multiple problem files remember to keep your edited copy of the domain file (with corrected requirements field, for example) safe from over-writing!

Secondly, you need to run the tool "pddl2lpgp" to convert to lpgp format. Run with "pddl2lpgp domain.pddl.untyped problem.pddl.untyped" and it will create "domain.pddl.untyped.lpgp", "problem.pddl.untyped.lpgp" and "problem.pddl.untyped.lpgp.durations" (see LPGPPROBS for examples).

Thirdly, try running LPGP: "lpgp domain.pddl.untyped.lpgp problem.untyped.pddl.lpgp problem.pddl.untyped.lpgp.durations". If it solves the problem (remember, this is an aging Graphplan planner, not a super-slick forward heuristic search planner), then you will probably want to see what the plan means. Try running it into a file "lpgp domain.pddl.untyped.lpgp problem.untyped.pddl.lpgp problem.pddl.untyped.lpgp.durations > file" and then run "showPlan file". This should produce a readable plan in the form VAL would expect. There is a slight oddity of STAN's output which means that actions with no arguments are printed with no leading bracket - we never did get round to fixing it!

Finally, a key issue when managing problems that involve required concurrency (such as the fusebox/match domain), it is necessary to manually tweak the postconditions of envelope actions (such as the burning match action) so that there is an end-effect that can be chosen to satisfy a goal. This is because LPGP does not have a mechanism to insert starts if there is no corresponding end and, because planning works backwards (Graphplan, remember), the end will only get inserted if it satisfies an existing goal. You can add a condition as a goal that is true in the initial state and is added by the end of the action you want to coerce: this acts as a choice point (include the action or don't). It is obviously easy enough to do this automatically, but we haven't got round to it.

Good luck and let us know if you want help getting it working. We'll always respond, even if we can't actually fix it for you!

Derek and Maria

derek@cis.strath.ac.uk
maria.fox@cis.strath.ac.uk