prolog-planning: A Prolog repository from krishnangovindraj

tl;dr

Toy prolog planner to play with simple planning problems. I read "Artificial Intelligence: A Modern Approach", but there's no regression planning like STRIPS in here (yet). The ideas of having an intial state, a goal-check and a set of actions (with pre-conditions, Delete lists, Add lists) stay and are used in the forward dfs. The nice quirk: Preconditions can be callable prolog predicates, (subject to conditions). See "Blocks example"

This cannot be used for serious planning problems. If that's what you need, Use a real solver.

Components

A declarative problem representation based on action/4: action(ActionSignature, PreconditionList, DeleteList, AddList).
A DFS with a depth-limit (and sometimes loop-detection), to do forward planning.
A DFS as above, but with some partial-order-reduction based on sleep-sets.
A really inefficient way of supporting constraints on the state
- by literally querying the state against the constraints after every action.
(in-progress) A minimal and (hopefully) easy way to explore plans which need some interaction, so you don't have to trace/spy.
A way to call python functions from prolog using an http server and JSON.
- Should be easy to adapt for your own needs, but it may need some tuning.
- See /json_client.pl and /python/*.py for more.
- I should rework this to convert things to problog/pylo terms in the python space.

YOU'LL PROBABLY HAVE A BAD TIME IF YOU DON'T READ THIS:

On simple programs with no variables in the state

The initial state MUST be ground.
Any variable appearing in the Add/Delete List MUST appear in the ActionSignature
All variables in an evaluate must be ground post evaluation OR not appear in the Delete/AddList. These together should guarantee that any state will be ground by construction.

If/When I (or you?) sit down to finally write a backwards planner, I will hopefully allow variables to be in the state. I don't even know if that's possible, but for now I have another approach:

On programs with perform/variables

Performs MUST FAIL if they do not meet their promises.
If following actions make no assumptions about the value of the variables (this includes structure, which is complicated for lists), you should be fine.
All variables must be ground after a perform is performed.

Blocks Example

/examples/blocks_plan.pl contains a simple planning problem in the block world (from AI:AMA), You can see how the actions are declared.

/examples/blocks_evaluate2.pl shows how the same problem is declared with callable prolog.

Running the examples.

Running the whole search at once:

$ prolog testbed.pl
?- representation:initialize_problem('examples/blocks_plan.pl').
?- initial_state(InitialPredicates), state_create(InitialPredicates, _S),!, 
        search_forward_dfs(_S, goal_check, 4, GL).
    InitialPredicates = [on(a, b), on_table(b), on_table(c), clear(a), clear(c)],
    _S = assert_state_d(103, meta(56283180, 5)), % Depends on the state-rep in state_manipulation.pl
    GL = [[move_from_table(b, c), move_to_table(a, b)], [move_from_table(b, c), move_to_table(a, c), move_block_to_block(a, b, c)]]. % The goal list, yay!

Using the interative file: $ prolog testbed.pl ?- use_module(interactive). ?- representation:initialize_problem('examples/blocks_plan.pl'). ?- initial_state(SL), interactive_init(SL). true. % HIT ENTER!!!

?- query_current_state(P). % Wanna see the state?
    P = on(a, b) ;
    P = on_table(b) ;
    P = on_table(c) ;
    P = clear(a) ;
    P = clear(c).

?- perform_search([on(b,c)], 4, P).
    P = [move_from_table(b, c), move_to_table(a, b)] ;
    P = [move_from_table(b, c), move_to_table(a, c), move_block_to_block(a, b, c)].

?- apply_action_path([move_from_table(b, c), move_to_table(a, b)]).
    true . % HIT ENTER!!! I'll sort this out later.

?- query_current_state(P). % See, it changed :)
    P = on_table(c) ;
    P = clear(a) ;
    P = on_table(a) ;
    P = clear(b) ;
    P = on(b, c).