PDDL Solver

Solver as a Service

The solver component of planning.domains is an automated planner and validator in the cloud. You can invoke the software either by sending links to the PDDL files or sending raw PDDL content in JSON format directly to retrieve or validate a plan.

Sending PDDL URLs

Primarily, this functionality demonstrates how to use the remote planner, and is used for debugging the output that may be provided when it fails to find a solution. As examples, see how to solve a simple blocksworld problem (a valid plan should be shown), and see what happens when you feed the planner mismatched problems (the planners error log should be shown).

Sending PDDL Directly

A JSON POST request to the solver and/or validator can be used to retrieve or validate a plan, and extra information will be returned as well. For now, this is just the ground action schema corresponding to each action in the plan computed, and the computed solution cost from the validator. More information may be added in the future, depending on the general interest of those using the service. The following API endpoints are available:

The solve and solve-and-validate endpoints require either probID or both domain and problem to be set as parameters. The former corresponds to the problem ID as defined by api.planning.domains and the latter can either be the raw PDDL text, or URLs to the domain and problem file. If URLs are used, then is_url additionally must be set to true. Finally, for the validate endpoint, plan must be set and correspond to the IPC standard plan output (i.e., one ground action per line).

The return value will depend on the endpoint used, but the status attribute will always be set to either ok or error. The result attribute will either be an error message (if appropriate), or contain information about the computed plan and/or validation. In particular, the following attributes may appear as part of the result:

Attribute	Description
length	Number of actions in the plan.
output	The planner output.
parse_status	Indication of the plan parsing (e.g., ok).
plan	List of action objects; each containing name and action (a string of the ground action).
type	The type of parsing (either simple or full) that was achieved. If simple, then the action objects in plan will just be action names.
cost	The plan cost.
val_stdout	VAL standard output.
val_stderr	VAL standard error.
val_status	The return status of VAL (either valid or err).
error	Indication of any VAL error.

Online Example

Aside from the integration into the online editor, you can invoke the planner on the range of domains provided by the API by going to this page. The same page is provided as part of the open source project to quickly test your own planner in the cloud as well.

Javascript Example

As an example, if domText and probText respectively contain the domain and problem PDDL text, then the following Javascript code would print the server response that includes the plan to the console (note that the jQuery library is required for the example):

$.ajax( {url: "http://solver.planning.domains/solve-and-validate",
  type: "POST",
  contentType: 'application/json',
  data: JSON.stringify({"domain": domText,
                        "problem": probText})})
    .done(function (res) {
      if (res['status'] === 'ok') {
        window.alert('Plan found!');
      } else {
        window.alert('Planning failed.');
      }
      console.log(res);
    }
);

Python Example

As another example, the following Python code can be considered a fully functional (albeit unreliable) IPC-style planner (i.e., run using ./planner.py domain.pddl problem.pddl plan.ipc):

import requests, sys

data = {'domain': open(sys.argv[1], 'r').read(),
        'problem': open(sys.argv[2], 'r').read()}

resp = requests.post('http://solver.planning.domains/solve',
                     verify=False, json=data).json()

with open(sys.argv[3], 'w') as f:
    f.write('\n'.join([act['name'] for act in resp['result']['plan']]))

Limitations

Currently the planner is limited to approximately 500Mb of RAM and has a 10 second time limit. Only one request can be served at a time, so it may take longer than 10 seconds for a response to be sent, and there is no guarantee that any request will be handled properly. If someone else requests the service while you are currently using it, you will need to wait at least 20 seconds before sending another request (until then, you will just receive a "Server Busy" response). This is to ensure that everyone gets a chance to use the service, and we avoid having a continual (re)planning approach monopolizing the time. These restrictions are due to the limited nature of the hosted solution for solver.planning.domains, and this is the primary purpose of releasing the framework for others to run their own private planner in the cloud.