Custom Delta Discretisation. ENHSP allows the use of a custom delta discretisation function both on the execution and on the planning decisions. Following the work by Ramirez et al. 2017, we can select a specific discretisation for how processes and events are treated, and a specific discretisation delta for when actions are going to be tried by the planner. This way, for instance, one can have a very precise delta for the execution, say 0.001 seconds, and therefore improve the chance to get plans which are valid against the continuous model, and a more coarse delta for the planning decisions, say 1 seconds. This idea has been used by many papers, for instance Kiam et al. 2020 and Aineto et al. 2023.
Custom Heuristic Functions.
Since ENHSP is written in Java and with modularity in mind, it is possible to extend it with user-defined functions, such as heuristics. To do so, download ENHSP from the github repository, checkout the enhsp-20 branch, and implement your heuristic as an implementation of the SearchHeuristic interface available in the Jpddl library used by enhsp.
The implementation of a custom heuristic is basically a class, and you can instantiate it in the setHeuristic method in the ENHSP.java file. The only things that need to be implemented for the class to be a valid implementation of the Search Heuristic interface are :
The method computeEstimate that takes as an input the current state and returns a float; The function is invoked passing the incumbent state, so everything inside the state can be accessed for reasoning purposes. Also, the heuristic can have as a constructor something that receives the specification of the problem, which can be yet another source of information for reasoning, such as transition models and goals.
The method getAllTransitions that basically returns all transitions that one is interested in the problem; this has to return a selection (potentially all) of actions and the set of processes and events in case the problem at hand is a PDDL+ one;
The method getTransitions that has to return a collection of actions (or helpful transitions). The boolean as an input is meant to indicate whether the heuristic can do some selection of the actions or not: this is used when one wants to let the search engine calling the heuristic decide when to use forms of pruning such as helpful actions (also referred as preferred operators).
We are aware that there maybe a better design choices for point 2 and 3: any suggestion is welcome!:)